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
> > reasons. If you're a Win32 programmer you'll be interested in the
> > implementation because it makes the semaphore and the mutex
> > operate much faster than the native Win32 equivalents and nearly
> > fast as the Win32 critical section. (I've not done timings, but
> > simple test harness illustrates this visibly!)
> > If you're not a Win32 programmer but are interested in the
> > library you may be interested in the implementation. There are
> > only two classes that use native code: atomic_t and semaphore.
> > atomic_t class is obviously preliminary, since we've hardly
> > 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
> > 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
> > 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
> > synchronization type is needed here to insure that we don't busy
> > unless we have to (the semaphore will be used for long term
> > 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
> > 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
> a separate class (basic_lock and frindes) to preform the lock
> a mutex ??? why the mutex class hasn't a lock and unlock
> this separate class (called basic_lock) still can have it onw
> the library, but why do you use it even in the mutex class ?
> much simpler and cleaner (at least for me) interface for mutex.
> anyway I prefere the name for this classes guard which can be
> to read_gurad, write_gurad at a higher level (but this is just
> 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
> function and I always prefere ansi function where it's possible
> in platform specific code. there is a clock() and other ansi
> to mesaure time.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk