Alex Rousskov wrote:
> Right, except that with AIO_PROPER_MUTEX undefined threads where
> using expensive "timed" condition wait,
True, but those timed condition waits was cheaper than correct
use of mutexes.
> and one could hardly add anything to the code without running
> into race conditions.
Can't comment on this as I don't know what you tried to do.
The code was designed with a specific purpose; dispatching blocking
operations on threads, and nothing else. All logic was kept in the
main thread.
> Also, without mutexes, the thread scheduling itself was
> "unpredictable" as some (all?) pthread man pages suggest.
Not much apart from the sheduling race condition which is not that
infrequent... ;-)
> Defining AIO_PROPER_MUTEX was not a good idea as well because then
> synchronization became extremely expensive.
On some platforms yes, but what did you do that was less expensive?
* condition variables is the only syncronisation primitive that is
available on all platforms used platforms.
* Proper use of condition variables requires locking and unlocking
of mutexes when signalling the condition to avoid the scheduling
race condition you refer to, as condition variables are unbuffered.
Multiple syncronisation variables was selected from the assumtion
that the main thread may need to activate more than one thread
before giving up the CPU, and that it is the number of mutex
locks/unlocks that is important and not the number of mutexes.
/Henrik
Received on Tue Jul 29 2003 - 13:15:53 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:55 MST