Re: RFC: Multithreading design constraints

From: Miki Jovanovic (miki_at_[hidden])
Date: 2000-06-06 10:30:24

--- In boost_at_[hidden], scleary_at_j... wrote:
> One thing we're going to have to settle on is terminology.  Here's 
> the terminology I have been using when dealing with multithreaded
> synchronization (it's a place to start):

Steve, good point. But please, can we start with a smaller list. We 
can't decide on 'Event' or 'Signal', let alone ona list as long as 
yours. Please, keep this list somewhere, and we will very seriously 
visit it once we have a base to work with.

I have suggested a list before, and Beman asked for a thread to be 
included in it. I also think that is a good idea.

Basic primitives:
 - thread
 - mutex
 - event
 - atom_traits

Mark also suggested a basic thread interface, but as noted before, I 
think we should get the requirements out before we get into interface 
design.

This said, I don't know where else to start then to list the 
functionality each primitive needs to support. Please note, that I am 
not suggesting classes with following methods, but rather a concept 
that allows certain functions.

thread:
 - start
 - stop
 - kill
 - join (with timeout)
 - set_priority (e.g. generic 1-10)

mutex:
 - lock (allows recursion)
 - attempt_lock (with timeout)
 - unlock

event:
 - set
 - reset
 - wait (with timeout)

atom_traits
 - read
 - write
 - add
 - test_and_set
 - test_and_reset
 - compare_and_exchange

OK, people, lets work the problem. Questions:

 - Do we need any other *basic* concepts?
 - Is the event better choice then conditional variable, keeping in 
mind that events keeps its state, and can release a single waiting 
thread rather then all of them?
 - Do we need to add/remove any functions on the primitives? (e.g. 
remove attampt_lock on mutex)

We also have a parallel discussion going on how best to use these 
primitives. The conversation revolved around a 'guard' or 'sync_lock' 
object that uses the scope to regulate the extent of the lock. The 
loudest voices said something like this:

mutex_guard:
 - constructor - locks the mutex
 - destructor - releases the mutex
 - acquire - locks the mutex if not already locked
 - release - releases mutex if not already released

Is this correct representation of what was said? And do you have 
something to add to this?

Cheers,

Miki.