Re: Threads: New Win32 Implementation

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-09-07 08:30:39

--- In boost_at_[hidden], Levente Farkas <lfarkas_at_m...> wrote:
> William Kempf wrote:
> > 
> > I've updated Win32_Threads.zip in the Threads folder with a newer
> > implementation.  This implementation is quite interesting for 
several
> > reasons.  If you're a Win32 programmer you'll be interested in the
> > implementation because it makes the semaphore and the mutex 
classes
> > operate much faster than the native Win32 equivalents and nearly 
as
> > fast as the Win32 critical section. (I've not done timings, but 
the
> > simple test harness illustrates this visibly!)
> > 
> > If you're not a Win32 programmer but are interested in the 
threading
> > library you may be interested in the implementation.  There are 
now
> > only two classes that use native code: atomic_t and semaphore.  
The
> > atomic_t class is obviously preliminary, since we've hardly 
finished
> > discussing it, but it's needed for the implementation of the
> > semaphore.  The semaphore has a slightly different interface than
> > that in Jeremy's Concept document, more closely resembling the 
Win32
> > semaphore concept, but this allows all the other synchronization
> > types to be built off of it.  The semaphore uses a single Win32
> > native type:  a Win32 event!  Blocking is controlled first by a 
spin
> > lock and then blocks on the event only if it truly needs to block.
> > This is what makes it nearly as fast as a critical section.  A 
native
> > synchronization type is needed here to insure that we don't busy 
wait
> > unless we have to (the semaphore will be used for long term 
locking).
> > 
> > Because all other types are built off of atomic_t and semaphore it
> > should be easier to port to other platforms.  At least that's the
> > theory.  It also illustrates why I think we need the primitives.
> > They can be used to build higher level abstractions.  Each level 
will
> > then be used to build yet higher level abstractions, etc.
> 
> I'm just skim your code and look good, but I've got two question:
> 1. this is in my mind form the begining of this thread. why do you 
use
>    a separate class (basic_lock and frindes) to preform the lock 
even on
>    a mutex ??? why the mutex class hasn't a lock and unlock 
functions ?
>    this separate class (called basic_lock) still can have it onw 
place in
>    the library, but why do you use it even in the mutex class ? 
it'd be 
>    much simpler and cleaner (at least for me) interface for mutex.
>    anyway I prefere the name for this classes guard which can be 
extended
>    to read_gurad, write_gurad at a higher level (but this is just 
more
>    obvious for me and not the most important part).

This is in the e-groups archive, as we've discussed it from the 
beginning.  Simply put, lock/unlock methods are dangerous to use, 
especially with exceptions.  If an "auto lock" class will do the same 
thing more safely, and with the same performance, then we're better 
off not exposing the lock/unlock functions at all.

As for the name... that's not as big of an issue right now.  I prefer 
lock, and you could still have read_lock, write_lock, etc.  I prefer 
it mostly because it's more intuitive to new users exactly what this 
means.  The interface isn't locked in yet, though, so the name isn't 
set in stone yet.

> 2. I realy hate when see the GetTickCount() funtion. it's not an 
ansi
>    function and I always prefere ansi function where it's possible 
even
>    in platform specific code. there is a clock() and other ansi 
function
>    to mesaure time.
> yours.

I considered this, but stuck with GetTickCount() because it is 
platform specific code and GetTickCount() returns milliseconds, 
whereas clock() would have to be used in a mathematical calculation 
using CLOCKS_PER_SEC to determine milliseconds.  So GetTickCount() 
seemed safe and much easier to deal with for this specific case.

Bill Kempf