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.
Mark also suggested a basic thread interface, but as noted before, I
think we should get the requirements out before we get into interface
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.
- join (with timeout)
- set_priority (e.g. generic 1-10)
- lock (allows recursion)
- attempt_lock (with timeout)
- wait (with timeout)
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:
- 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk