From: William Kempf (sirwillard_at_[hidden])
Date: 2000-09-07 09:15:33
--- In boost_at_[hidden], Levente Farkas <lfarkas_at_m...> wrote:
> William Kempf wrote:
> > 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
> > thing more safely, and with the same performance, then we're
> > off not exposing the lock/unlock functions at all.
> I didn't read the archive, but this is not true. it's one of the
> problem in java thread (and that was one of the main reason that in
> year on javaone at least 3 main session about "a new concurent
> java"), the syncronyzed keyword have to be around a block, auto-
> always do the same thing, ie. you can't do the following:
> Mutex m1, m2;
> <may be some code>
> <may be some code>
> <may be some code>
> in the current setup a we loose a BIG functionality!!!
Nope. C++ isn't Java. If we absolutely had to have overlapping
locks like that we could place the locks on the heap. Thus 'm1.lock
()' becomes 'plk1 = new mutex::lock(m1)' and 'm1.unlock()'
becomes 'delete plk1'. Ugly? Yes, but that could be considered a
good thing, since it puts up a red flag that what we're doing is
If that's not good enough, the better solution than exposing
lock/unlock on the mutex is to add lock/unlock functions to the lock
objects, though I wouldn't recommend it (this reduces the safety of
the condition::wait() since we're no longer assured that the mutex is
The simple fact, to me at least, is that the example you give here is
EXTREMELY rare, and in fact should be avoided when possible for
numerous reasons. How often have you really had a need to use
> those user who would like to write safe code will always use the
> guard/auto_lock, but if the problem/solution requires he can lock
> Sometimes it's a must that lock in one function and unlock in
Another very rare need indeed! Also "solvable" by placing the lock
on the heap (and probably using an auto_ptr to pass it around!).
> I think the above argument is that we have to suuport all stupid
> programmes too not the best choise. I always prefere safe code over
> even if it's same preformance loose, but the above have too much
> (anyway in java assamply you can do the lock and unlock but not in
> java code).
We don't have to work around the problem here, we just have to use
the lock in a different manner. Portable, relatively safe and
strongly illustrates the dangers when used.
> > As for the name... that's not as big of an issue right now. I
> > lock, and you could still have read_lock, write_lock, etc. I
> > it mostly because it's more intuitive to new users exactly what
> > means. The interface isn't locked in yet, though, so the name
> > set in stone yet.
> my naming convention come from the above statement, if the the
> function used it's easier to remember as a function and guard as an
Well, I still don't think you want to expose the function so I'm
still in favor of lock as the name for the "auto lock".
> > > 2. I realy hate when see the GetTickCount() funtion. it's not an
> > ansi
> > > function and I always prefere ansi function where it's
> > 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
> > using CLOCKS_PER_SEC to determine milliseconds. So GetTickCount()
> > seemed safe and much easier to deal with for this specific case.
> I think eevn it's platform specific code most of these line can be
> on all platform, but in this case a few less lines:-)(
A very few less. I can change it if it's that large of an issue...
remember this code is a proof of concept and not a submission for
acceptance into boost. I feel justified in how it's coded now, but
if the code should ever progress to the point where it will be
submitted for boost approval then I could be persuaded to modify this.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk