tags:

views:

38

answers:

3

I am writing a program with a few critical sections. The thing is I need to check the value of a mutex in an if statement.

I would like to do something like this:

if pthread_mutex(&mutex) == 0 // locked 
  // Do something
else if pthread_mutex(&mutex) == 1 // unlocked 
 // Do something else

Is this possible?

+5  A: 

You want pthread_mutex_trylock().

From that link:

The pthread_mutex_trylock() function shall be equivalent to pthread_mutex_lock(), except that if the mutex object referenced by mutex is currently locked (by any thread, including the current thread), the call shall return immediately. ... Return values ... The pthread_mutex_trylock() function shall return zero if a lock on the mutex object referenced by mutex is acquired. Otherwise, an error number is returned to indicate the error

So your code would go like this:

pthread_mutex_t *m = /* ... */;

if (pthread_mutex_trylock(m) == 0)
{
    /* Success!  This thread now owns the lock. */
}
else
{
    /* Fail!  This thread doesn't own the lock.  Do something else... */
}
asveikau
Yep, if successful, unlock it again. PS: I battled with it yesterday: http://stackoverflow.com/questions/3931026/how-can-i-synchronize-three-threads
slashmais
Thanks! I am pretty sure this will work out well.
Google
Can I evaluate the lock and not lock it? I would like to evaluate a lock and then levy a sem_wait/post depending on a lock.
Google
Through POSIX, the answer is no. If you implement your own lock based on compare-and-swap then yes, you can, but keep in mind that *after* you read the value there's nothing to stop something from acquiring the lock and screwing you up. You have to understand that there's lots of inherent race conditions in what you're asking for.
asveikau
Ahh thanks, I think I will need to re-work the code and only use semaphores instead of mutex locks. Hmm, complicated topic!
Google
A: 

If you want to know if your mutex is already locked, I suggest you use pthread_mutex_trylock. Keep in mind that locking a mutex is an heavy operation, you shouldn't lock it just to test if it wasn't.

Opera
+2  A: 

No you shouldn't try to do that. I think, pthread mutexes are made to regulate local access to some critical resource, and if at a place your program doesn't know if this actual thread holds the lock, you are using the wrong tool. I see two alternatives:

  • keep a variable on the stack of the function where you keep track that it is locked here, or if really necessary store the thread id and compare to that
  • switch to sem_t as control DS. they don't have this restriction of being glued to a specific thread that "holds" them, but are token based, so any thread that obtains the token may do the work that is required. (but be careful and check the return value of the functions these routines may be interrupted.)
Jens Gustedt
I am trying to use a combination of both, it's quite troubling to solve the problem. I may need to re-work the whole solution.
Google