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.