Re: Threads: New Win32 Implementation

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 
called
> 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 
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.
> 
> 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 
calculation
> > > 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