This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Optimization of conditional access to globals: thread-unsafe?


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]