posix mutex

[efe909]

Hi, I am learning multi-threaded programming (C++) using POSIX libraries.
I have been using the mutex's perfectly well yet I want to clarify something. In almost all examples that introduce mutex use the bathroom key metaphor, yet as I realized, it is possible for a function to access a variable with no problem if it does not bother to use/check the mutex created with the intention to protect it. Thus using the same metaphor the bathroom can be used even without the key. Then, a better metaphor should be defining mutex as a sign that signals whether one is using the bathroom or not (e.g. a red light), since if one does not bother to check the sign, he/she can still use it with the risk of finding someone using it already.
What do you think?

[kbw]

I'm really not sure what you mean, but the issue is this. You cannot read and write data at the same time, there has to be some mechanism that ensures that this doesn't happen.

Multiple threads of execution can access resources, and as long as they don't do it simultaneously, they don't need to be synchronised. The catch is, any mechanism used to separate them must be atomic (it must still work in a context swapping environment).

It was for this reason that the semaphore was devised (by Disjkstra). A mutex is a special case of a semaphore.

There is a try-lock thing that allows to a thread to test if it would block. I guess that's the equivalent to your red-light system.

[efe909]

Hi my point is very simple (I believe), consider the following code:
...
pthread_mutex_t mymutex = PTHREAD_MUTEX_INITIALIZER;
int myVariable;

void someFunction(void){
myVariable = 21;
}

void nicerFunction(void){
pthread_mutex_lock( &mymutex );
myVariable = 21;
pthread_mutex_unlock( &mymutex );
}

so the thread safe way is to use the nicerFunction yet, one can use someFunction with the obvious risk. My point is, access to variable myVariable is not really "locked" if one does not bother to check the mutex (like someFunction).

So if I am right (which may not be) using the metaphor of lock is not proper. A mutex acts as a lock only if you bother to check its state and set your code accordingly, otherwise any function can access the supposedly protected variables, e.g. anyone can get into the room while someone else was using it.

[kbw]

My point is, access to variable myVariable is not really "locked" if one does not bother to check the mutex (like someFunction).

Yes, and we'll agree that's incorrect.

A mutex acts as a lock only if you bother to check its state and set your code accordingly, otherwise any function can access the supposedly protected variables, e.g. anyone can get into the room while someone else was using it.

If you acquire the mutex, you're in. The mutex provides that guarantee, there's nothing to check.

Clearly, you need to provide the protection. You're not protected by default, the language provides no such guarantee.

Just to be clear, there is no protection provided by C/C++. You have to do it yourself using the atomic mutex or semaphore provided by the OS.

[zb0S216C]

efe909 wrote:

"access to variable myVariable is not really "locked" if one does not bother to check the mutex"

If you have to check if a thread has acquired the lock then you're doing it wrong. The whole point of mutual exclusion (mutex) is that threads have synchronised access to some resource. If you don't use any synchronisation methods then you're using lock-less code. Normally, mutual exclusion forces threads to either spin and wait (spin-locking) or do something while it's waiting (busy-wait). Once a thread is granted access to the resource, the thread does its thing; otherwise, the thread will wait. There's no need to check if the thread has the lock.

efe909 wrote:

"A mutex acts as a lock only if you bother to check its state and set your code accordingly, otherwise any function can access the supposedly protected variables"

True, but the whole point of mutual exclusion is to prevent threads from such access. If a thread bypasses the mutex protecting the resource then race-conditions ensue. It's the programmer's responsibility to ensure threads are synchronised when accessing a common resource.

_Wazzak