Re: thread::mutex lock problem, a bug?

Well, starving... no wonder! You have a tight loop w/o any
potential yield points. Normally at some point in your code
the thread should "yield" allowing the scheduler to run
another thread. If you call any of certain system calls
like read, write, select etc... the scheduler willl put your
thread to sleep and run the next thread which is ready to
run. If your code does not call any of those, as in your example,
then it might be that one thread works for couple of seconds
before its quantum is expired. This all is pretty OS dependent
and you will get different results on different boxes.

I cannot consider this a bug. This is just a normal behaviour.
If you put "after 1" somewhere in your loop, the "starvation"
will dissapear.

The original problem you posted was a real show-stopper.
I had a very stupid race condition there (I was naive) which
led to a deadly-embrace type of problem. This is now fixed.

Cheers
Zoran

.