Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-09-08 09:17:00

--- In boost_at_[hidden], "Milutin Jovanovic" <miki_at_o...> wrote:
> Huh, I have been away for just a little while, and hundreds of
messages are
> waiting for me. If some of my comments are to the old topics,
please excuse
> me...
> From: "Levente Farkas" <lfarkas_at_m...>
> > always do the same thing, ie. you can't do the following:
> > Mutex m1, m2;
> > m1.lock();
> > <may be some code>
> > m2.lock();
> > <may be some code>
> > m1.unlock();
> > <may be some code>
> > m2.unlock();
> > in the current setup a we loose a BIG functionality!!!
> True, but I solved this with a unlock() or release() provided in
the lock
> class. Lock class can unlock the mutex only once, so if the user
> unlock() explicitly, destructor will not do anything. Solved. On
the other
> hand, I do not like having lock() method added to the lock class...

Nope, this is not a solution. This removes the compile time check
that insures the mutex is locked before calling condition::wait().
However, I don't believe there's a problem here, and I've explained
why several times in other posts. You simply place the lock on the
heap to gain explicit control over locking/unlocking for these corner
cases (and they are very rare cases, IMHO).

> > > 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.
> How about the lock being the subclass of mutex? I always used
> class Mutex {
> public:
> class Lock {
> };
> };
> That way I can have in my code something like:
> void dummy() {
> Mutex::Lock mylock( mx_something );
> // code...
> }

Check out Jeremy's Concept documents and his or my implementations.
This is precisely what we've done.
> > > 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.
> But why call it tick? I am not aware of any official unit called
tick. Any
> of GetMilliseconds() GetMillis() GetMillisecondCount() are much more
> selfexplanatory.

Sorry, you misunderstand the issue here. GetTickCount() isn't my
function, it's a Win32 API. So I had no choice about the name,
though I'd agree that MS did a poor job naming this API. The
argument was against using a Win32 API when an ANSI function exists
to do the same thing. I explained that I chose the Win32 API for
ease of use, since it's gauranteed to return milliseconds while clock
() must be converted to milliseconds using CLOCKS_PER_SEC. A trivial
issue, IMHO, especially since this is concept code and not a
submission for Boost.
Bill Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at