Re: [boost] RFC: Multithreading design constraints

From: mwa_at_[hidden]
Date: 2000-06-06 09:37:39

Hi everyone,

I've been lurking here for a while, and this is an area of class library 
design in which I am very interested.

Additional comments on terminology:

  Mutex - (Also called "Binary Semaphore").  Either locked or unlocked.
Initialized to unlocked.  Any thread may lock it, which (if it is already
locked) will block until unlocked.  Any thread may unlock it if it is
locked.

One other thing that needs to be covered is the semantics in the case of a 
thread acquiring a mutex it already owns.  Does the thread block (in a 
deadlock-type fashion), or does it simply note that it has been acquired, 
and allow it to continue.  In that case, does it need to release the mutex 
only once?

  Semaphore - Has a free count, passed to the initialization routine.  Any
thread may lock it; if the free count is 0, that thread will block until 
it
is unlocked; otherwise, the free count is decremented.  Any thread may
unlock it, which increments the free count.

This definition probably needs to be tightened.  What about the case where 
one thread sits in a loop freeing the Semaphore? The free count can then 
become arbitrarily high, which defeats the 'limited resource' semantics fo 
the semaphore. I would prefer 'Any thread which has previously locked the 
semaphore may unlock it', but this is not the only alternative.

  Event - Either signalled or unsignalled.  Any thread may set the state 
to
signalled.  Any thread may set the state to unsignalled.  Any thread may
wait for the state to become signalled, which will block until the state 
is
signalled.
  Gate - Either open or closed.  Any thread may open the gate.  Any thread
may close the gate.  Any thread may wait for the gate to open, which will
block until the gate is open.  Any thread may atomically open and close 
the
gate, releasing any waiting threads.

I'm not too clear what the difference between these is, as Opening the 
gate alone will release those threads that were waiting when you started 
opening the gate, and any others that make it there before you close the 
gate again. Is 'open and close' an atomic operation that will not allow 
any threads that were not blocking when the decision was made to open the 
gate to join the waiting queue?  If so, why?  If not, then why can't you 
just use an event? What does 'automatically' mean?

Thanks for your time,

Matthew Adams
---
Development Manager
Digital Healthcare Ltd
Unit 204
Cambridge Science Park
Milton Road
Cambridge
CB4 2PA
Tel: [phone]
www.digital-healthcare.com
scleary_at_[hidden]
06/06/2000 15:04
Please respond to boost
 
        To:     boost_at_[hidden]
        cc: 
        Subject:        [boost] RFC: Multithreading design constraints
P.S.  One thing I have not been able to dream up is an efficient portable
interface for is waiting for multiple objects (multiple events, etc). 
Maybe
we could just provide an "accessor" member function with a
platform-dependent return type for now, and let any such multiple waits be
in the user code, specific to the platform.
P.P.S.  The list of primitives above is not complete -- spin locks, etc. I
have not yet worked with at all.
------------------------------------------------------------------------
IT Professionals: Match your unique skills with the best IT projects at
http://click.egroups.com/1/3381/3/_/9351/_/960300382/
------------------------------------------------------------------------
[Non-text portions of this message have been removed]