Re: RFC: Multithreading design constraints

From: Miki Jovanovic (miki_at_[hidden])
Date: 2000-06-05 13:39:45

--- In boost_at_[hidden], jsiek_at_l... wrote:
> It seems to me that having all these operations
> (read/write/add/test&set/exchange) is a bit overkill. What's wrong
> with just a plain old mutex (with lock/unlock).  Is there that much 
> of a performance difference to be gained?

Possibly. atomic_traits class is a set of utilities built on top of 
mutex. But this organization allows it to be optimised for particular 
platforms.

> Oh, and along the lines of Steve's comment about signaling locks, 
> etc. the notions of a semaphore and of a condition variable (both 
> are in posix threads) are certainly important... probably important
> enough to be considered separately from mutexes.

I strongly suggest we draw a line between basic promitives and 
extended synchronisation. Basic primitives should in my view include 
only:

 - mutex
 - signal
 - atomic_traits

mutex and signal are absolutely the most basic primitives, and 
atomic_traits allow for optimisation of extended synchronisation 
functionality.

Once we are happy with the basic primitives, then we can work on 
semaphores and conditinal variables. And the most beautiful part is 
that we will already have a standard library, because all of these 
extended classes can be implemented in terms of basic ones.

If we keep it KISS, we will have a powerful foundation on top of
which we can make a multithreading library as varied as we want. Does 
this make any sence?

Cheers,

Miki.