check if a pthread lock variable is locked

Question

I want to find out if a pthread lock variable is locked or not. One simple approach is to use a trylock as shown below

pthread_mutex_t lockVar;
if(pthread_mutex_trylock(&lockVar) == 0)
{
    //lock was successful
    pthread_mutex_unlock(&lockVar);
}
else
{
    //someone else holds the lock
}

How do I do the same thing without obtaining a lock?

Answer 1

When you have multiple executions happening concurrently, there is no notion of "simultaneity". Events cannot be given a global order in time, except for when explicit synchronizations happen. There is no property that's observable from within the language that can observe any kind of ordering in general.

Specifically, the question "is that mutex over there locked" is meaningless. It has no answer upon which you can act. Whatever the fictitious answer is, the state of the mutex can change right after. There is nothing you can do with an answer like "yes, it's locked" (it might become unlocked at the same time), or "no, it's unlocked" (it may get locked before you get there).

The only thing you can do with a mutex is try to lock it. You either fail, and thus know that it was locked, or you succeed and thus know that it wasn't, and now you have the lock.

Answer 2

Regardless of what you want to do with the result, the way you're doing it right now is the only way. You cannot simply query whether a mutex is locked without locking it. If you want a synchronization primitive for which you can query the status without modifying it, POSIX semaphores would be a possibility. A binary semaphore can serve as a lock (although it lacks the concept of an owner, which may be a problem for you if you need recursive locking) and sem_getvalue can determine whether or not the semaphore is "locked" at a single moment in time.

As for whether the question you're asking is even meaningful, Kerrek has already told you it's usually not. Here are a few possible, minimally-useful pieces of information you could gather from negative or positive results:

• Negative:

  • If you know the lock started out locked, and won't be locked again once it's unlocked, this tells you an operation has finished. Here, a trylock-and-unlock approach would prevent multiple threads from being able to do this, since it would break the "never locked again once it's unlocked" invariant.
  • May indicate that it's worth preparing data, without the lock held, that you could apply later via trylock/unlock held only for a brief interval once the data is prepared. But of course you have to prepare for the case where things have changed by the time you take the lock later.

• Positive:

  • If you know that the lock will not be unlocked once it's taken until your thread performs a further action allowing the lock-holder to proceed, this gives you information that a lock-holder has arrived.
• Maybe others...

But for the most part, "is the mutex locked?" is not a useful question.