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.
-- Levente http://petition.eurolinux.org/index_html
"The only thing worse than not knowing the truth is
ruining the bliss of ignorance."
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk