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