On 27/10, Robert Dewar wrote: > I don't understand, are we looking at the same example, the example > from Sam that I looked at did not have an entry body, so how could the > entry body rule apply?
Let's look at the example (where I replaced protected procedures by entries with a guard which is always True). As per RM95 9.10, I understand that the calls to Maybe_Lock/Maybe_Unlock act as a synchronization point for two tasks executing Maybe_Increment: http://pastebin.com/f35d673e9 This looks to me like a proper way to "synchronize the actions of two or more tasks to allow, for example, meaningful communication by the direct updating and reading of variables shared between the tasks" (RM citation). However, despite the fact that the first task will get what looks like a lock (L is True), with the current "optimization" the other one will be able to modify the Shared variable even though the Ada code is not supposed to read or write in its memory location (as L will be False in the second task since the lock has not been acquired as it has been granted to the first task). I admit that this example may be contrived and not occur in real-life code, but I am surprised that Ada allows the Shared variable to be updated to its older value by a race condition in this case.
