Re: [boost] Re: Threads: New Win32 Implementation

From: Milutin Jovanovic (miki_at_[hidden])
Date: 2000-09-08 08:41:52

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_[hidden]>
> 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...

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

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

Cheers,

Miki Jovanovic.