12-28-2009
Mutexes, semaphores, and atomic operations have been around for decades, have been used by untold numbers of programmers, and have been examined, re-examined, and otherwise worked on by probably thousands of computer scientists and programmers of which probably more than a few have done Nobel-prize level work in science and/or mathematics.
They're mature, stable, and work without fail.
They're also just about as fast as possible.
If you think you can do better, go ahead. You may very well come up with something that's better. But be sure when you're done developing your alternative, you compare the performance you get to the OS-supplied mutexes, semaphores and atomic operations, because coming up with something better is going to be very hard to do.
But if you can do it, it would be great.
10 More Discussions You Might Find Interesting
1. Programming
Hi all,
I am working in a UNIX/C environment. I would like to understand more about MUTEX and Threads. Can someone explain me these
concepts and how they are related.
Vijay (2 Replies)
Discussion started by: vthasan
2 Replies
2. UNIX for Dummies Questions & Answers
Can anyone explain me what mutexes are in
multithreading environment? (2 Replies)
Discussion started by: sagar
2 Replies
3. Shell Programming and Scripting
A shell in crontab per 5 min write a file
B shell in crontab per 6 min read a file
how to lock the share file a ;avioid confilict in write and read?
Thx : -) (1 Reply)
Discussion started by: zz_xm
1 Replies
4. Programming
Hi, I have two tasks 'Read' and 'Write' which reads and writes on a file "abc.txt" respectively.
Now I need to restrict the Write operation on the file while Read is going on, But can allow two Reads at a time.
ie. two Reads can happen simultaneously, but Write can't happen at Read is going on.
... (3 Replies)
Discussion started by: satheeshalle
3 Replies
5. Programming
Hi,
can someone explain me the difference between mutex and semaphores?
Thanks (1 Reply)
Discussion started by: rvan
1 Replies
6. UNIX for Dummies Questions & Answers
can u tell me what is the exact difference b/w mutex and semaphore
and what is the diff b/w counting semaphore and binary semaphore
amit (1 Reply)
Discussion started by: amitpansuria
1 Replies
7. Shell Programming and Scripting
Hello Everyone,
I just joined this forum and this is my first post.
I would like to know how can I impliment basic read/write locks in perl. I have a database (file) which can be accessed simultaneously but has to be locked while writing.
If there is no such support in perl, my next... (6 Replies)
Discussion started by: superuser84
6 Replies
8. Programming
I am trying to use mutex in my multi-tread project, but they don't seem to work.
I have created a simple demonstration of the problem. This is NOT how I would use a mutex, only a demonstration of the problem:
#include <stdio.h>
#include <pthread.h>
int main()
{
int val;
... (3 Replies)
Discussion started by: ChrisWilliams
3 Replies
9. Programming
Hi all,
I have a scenario where I need to use the mutex locks. The mutex locks are working fine, but sometimes I am getting into the dead lock situation.
Below is the summary of my code :
MUTEX LOCK
performTask();
MUTEX UNLOCK.
In some cases I get into the situation where... (2 Replies)
Discussion started by: cjjoy
2 Replies
10. Programming
Hello,
I have got some issue with the struct variable with passed arguments
the variable in the sturct is only recognize the last value their assigned to
I'm pretty confused why the mutex didn't work out
here is my program:
#include<stdio.h>
#include<pthread.h>
pthread_mutex_t lock... (3 Replies)
Discussion started by: michael23
3 Replies
LEARN ABOUT DEBIAN
xparace
xparace(3) SAORD Documentation xparace(3)
NAME
XPARace - XPA Race Conditions
SYNOPSIS
Potential XPA race conditions and how to avoid them.
DESCRIPTION
Currently, there is only one known circumstance in which XPA can get (temporarily) deadlocked in a race condition: if two or more XPA
servers send messages to one another using an XPA client routine such as XPASet(), they can deadlock while each waits for the other server
to respond. (This can happen if the servers call XPAPoll() with a time limit, and send messages in between the polling call.) The reason
this happens is that both client routines send a string to the other server to establish the handshake and then wait for the server
response. Since each client is waiting for a response, neither is able to enter its event-handling loop and respond to the other's request.
This deadlock will continue until one of the timeout periods expire, at which point an error condition will be triggered and the timed-out
server will return to its event loop.
Starting with version 2.1.6, this rare race condition can be avoided by setting the XPA_IOCALLSXPA environment variable for servers that
will make client calls. Setting this variable causes all XPA socket IO calls to process outstanding XPA requests whenever the primary
socket is not ready for IO. This means that a server making a client call will (recursively) process incoming server requests while waiting
for client completion. It also means that a server callback routine can handle incoming XPA messages if it makes its own XPA call. The
semi-public routine oldvalue=XPAIOCallsXPA(newvalue) can be used to turn this behavior off and on temporarily. Passing a 0 will turn off IO
processing, 1 will turn it back on. The old value is returned by the call.
By default, the XPA_IOCALLSXPA option is turned off, because we judge that the added code complication and overhead involved will not be
justified by the amount of its use. Moreover, processing XPA requests within socket IO can lead to non-intuitive results, since incoming
server requests will not necessarily be processed to completion in the order in which they are received.
Aside from setting XPA_IOCALLSXPA, the simplest way to avoid this race condition is to multi-process: when you want to send a client mes-
sage, simply start a separate process to call the client routine, so that the server is not stopped. It probably is fastest and easiest to
use fork() and then have the child call the client routine and exit. But you also can use either the system() or popen() routine to start
one of the command line programs and do the same thing. Alternatively, you can use XPA's internal launch() routine instead of system().
Based on fork() and exec(), this routine is more secure than system() because it does not call /bin/sh.
Starting with version 2.1.5, you also can send an XPAInfo() message with the mode string "ack=false". This will cause the client to send a
message to the server and then exit without waiting for any return message from the server. This UDP-like behavior will avoid the server
deadlock when sending short XPAInfo messages.
SEE ALSO
See xpa(7) for a list of XPA help pages
version 2.1.14 June 7, 2012 xparace(3)