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

OK. I now understand why I did not get the problem before.
Yes, there is again an race condition there. I'm afraid I'm
trying to be too clever at one place. I guess I will have to
remove that check eventually...

The reason I never spotted that problem was: normally you need
not lock the mutex before calling the [thread::cond notify].
So in your Thread2 and Thread3, locking of the mutex can be
avoided. But, as an exercise, this has revealed yet-another
race which I obviously added by doing the last changes.
Well, I said there might be new bugs introdoced...

I will have to see wether it is possible at all to fix that so that
the error gets triggered if somebody is trying to wait on the
cond variable w/o locking the mutex before. If not, I will remove
that check altogether.

.

Relevant Pages

  • Re: How do I ensure only one version of my executable is running
    ... simultaneously started, check for the mutex, see it's not there, and ... your mutex solution does not have a race condition. ... But the shared data segment solution can also be coded that way. ... find the window for Instance 1. ...
    (microsoft.public.vc.mfc)
  • Re: msleep() on recursivly locked mutexes
    ... If you hold a mutex and release it during sleep you probably should invalidate all assumptions you made during the period before you slept as whatever you were protecting has possibly been raped while you slept. ... And interesting observation here is that FreeBSD 4.x and earlier were actually rife with exactly this sort of race condition, exercised only when under kernel memory pressure because sleeping occurred only then. ... The explicit locking model we use now makes these races larger due increased concurrency, but also makes our assertion model stronger. ...
    (freebsd-hackers)
  • Re: Select system call
    ... the same descriptor and the same operation? ... didn't it could lead a race condition? ... i think you need a semaphore or a mutex. ...
    (comp.unix.programmer)