Re: [boost] Threads: New Win32 Implementation

From: Levente Farkas (lfarkas_at_[hidden])
Date: 2000-09-07 04:26:05

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).
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.

 -- Levente                           http://petition.eurolinux.org/index_html
 "The only thing worse than not knowing the truth is
  ruining the bliss of ignorance."