[concurrency-interest] Is there something like an ordered or counting barrier

David Holmes dholmes@dltech.com.au
Thu, 30 Dec 2004 08:45:55 +1000


Oliver,


> Sometimes stuff is even more complicated. Consider you want to signal
> the next turn, but are blocked by a lock before doing so. The thread
> that will release your block however needs your next signal to
> proceede. My solution looks like
>
> waitForTurn(0);
> synchronized (lock) {
>   signalNextTurn(0);
>   lock.acquireSomething();
> }
>
> and the other thread may look like
>
> waitForTurn(1);
> synchronized (lock) {
>   signalNextTurn(1);
>   lock.releaseSomething();
> }
>
> I thought all this was a very common problem. How are others dealing
> with it? Is this an absurd approach?

Basically you don't code things with such dependencies because of the
deadlocks involved. One solution if these dependencies exist is to release
the lock before doing the signal.

In your code above, however, I don't know what lock.acquireSomething and
lock.releaseSomething actually represent. Also you don't synchronize on lock
before waitingForTurn, so a deadlock should not exist.

You mentioned in the original post that this was to support testing of your
multi-threaded code. But this ad-hoc scheduling protocol you are trying to
construct is probably more susceptible to errors than the code you are
testing. And the resulting code will not execute in the same way as the
original anyway.

I would take a step back and consider what it is that you really want to do.

David Holmes