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

Oliver Zeigermann ozeigermann@apache.org
Thu, 30 Dec 2004 00:06:25 +0100

Hi David,

thanks again for your input :)

On Thu, 30 Dec 2004 08:45:55 +1000, David Holmes <dholmes@dltech.com.au> wrote:
> > 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.

OK, I have confused you now. Sorry for that. The above code is for
checking if acquiring and releasing of a blocking lock works. All this
is a Junit test.

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

Of course you have to be careful with the construction of such a test
case, but - and this is what I am asking - what is the alternative?
How do others test their lock classes? You need multiple threads, but
then you need them to execute in a deterministic way to reproduce the
test scenarios you want to check.

How has java.util.concurrent been tested? OK, I will ask this in
another thread...

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

Either the stuff I described above or I am totally mad ;)