From: davlet_panech (davlet_panech_at_[hidden])
Date: 2002-01-29 12:24:02
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk