Boost.Threads: volatile methods of mutex class

From: davlet_panech (davlet_panech_at_[hidden])
Date: 2002-01-29 12:24:02

Good day,

I was wondering whether the lock/unlock methods of the mutex class 
should be changed to volatile. I guess not having them as volatile is 
OK as long as the underlying OS supports mutexes directly. Unless I 
am mistaken, in POSIX the pthread_mutex_t type could be implemented 
in terms of a semaphore, i.e., as a structure containing a semaphore 
id and the id of the thread that owns the mutex. Anyhow, I don't know 
for sure if this might be the case in POSIX, the real reason I am 
bringing this up is because I recently ported (portions of) 
Boost.Threads to a platform (pSOS) that doesn't support mutexes, only 
semaphores. My mutex class ended up containing a system semaphore ID 
and a pointer to the owner thread, used to allow recursive locks. 
This value (pointer to the owner thread) is tested and assigned to 
when different threads lock and unlock the mutex; this may result (I 
think) in incorrect behaviour if the compiler optimizes out those 
tests and assignments.

I propose that we make sure that places like scoped_lock constructor 
take a reference to a volatile mutex, instead of a plain one.

Does that make any sense?

Thank you,
D.P.