[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Error admitted: another notifyAll() too little

Referring to chapter 5 in Æ1Å, the authors have now found out 
that a notify() should have been a notifyAll(). They ponder this,
and more, in a new addendum Æ2Å. They had to run a more thorough
"property" analysis by making a model of the implementation.

>From Æ2Å:

"With two producer processes and two consumer processses and a
buffer with two slots, safety analysis by the LTSA reveals no 
property violations or deadlocks. In this situation, the
implementation satisfies the design. However, safety analysis with
two produces processes, two consumer processes and a buffer with
only one slot reveals the following deadlock: ...
...This deadlock occurs if either the number of producer processes
or the number of consumer processes is greater than the number of
slots in the buffer.
...The lesson here is that it is always safer to use notifyAll()
unless it can be rigorously shown that notify() works correctly.
We should have followed our advice in Chapter 5! The general rule 
is that notify() should only be used if at most one thread can
benifit from the state of change being signalled and it can be
guaranteed that the notification will go to a thread that is waiting
for that particular state change. An implementation model is a
good way of doing this."

The scaring thing is that the Java code fits in one small page!
Another good case for the Java CSP stuff!

  CONCURRENCY, State Models & Java Programs. Magee & Kramer


)       Oyvind Teig )          oyvind.teig@xxxxxxxxxxxx ) Tel: +47 )
( Navia Maritime AS (          oyvind.teig@xxxxxxxxxxxx ( 73581268 (
)    div. Autronica )                                   )          )
(              7005 (               http://www.navia.no ( Fax: +47 (
)          Trondhem )           http://www.autronica.no ) 73919320 )
(            Norway ( http://www.autronica-maritime.com (          (