In <1992Oct7.144936.1...@bony1.bony.com> rich...@bony1.bony.com
(Richard Bielak) writes:I didn't express myself clearly in my previous posting. I'll try again.
>cjmch...@dsg.cs.tcd.ie (Ciaran McHale) writes:
>>>>[can pre-/post-conditions be evaluated safely in the face of concurrent
>>>You can divide features of a class into "querries" and "commands".
>>>Querries only read the object's attributes and return some value.
>>>Commands modify the object.
>>Indeed, that is one way to handle it. But it has some limitations:
>> o The readers/writer (queries/commands as you call them) policy
>Since objects contain data and concurrent objects contain data shared
Consider the following class:
Basically, B is a writer on one part of the object (the variable "y")
1. B cannot execute if B is already executing (i.e., mutex with
Notice that the potential concurrency is greater than than allowed by
Now let us consider how certain pre-conditions may restrict the
A's precondition reads the value of "y", which is updated in B. Thus,
1. as stated previously.
Because there is a strong link between the evaluation of A's
1. B cannot execute if A or B is executing.
While this is certainly a possible solution, it is constricting the
That's what I tried (but failed:-) to say in my previous posting.
I agree with Richard that:
>Since objects contain data and concurrent objects contain data sharedHowever, unfortunately, pre-/post-conditions seem to reduce the
>by many threads, so the concurrency *must* be constrained.
potential for concurrency within an object. This is _not_ to say that
pre-/post-conditions are a bad idea; only that more work needs to be
done to integrate them with synchronisation mechanisms.
BTW, Maurice Herlihy holds a rather different opinion on concurrency
>> o Most likely it would be the programmer's responsibility toWhat I meant by that comment is that programmers know they have to look
>> take the pre-/post-conditions into account when writing the
>> synchronisation code for the object. I think this gives
>> programmers more than enough rope to hang themselves with.
>By default all routines could be "readers" (querries). Additional
at the code bodies of operations when they are deciding on a
synchronisation policy for the object, but they may fail to _also_ take
pre-/post-conditions into account when doing this. I think this issue
is independant of whether one expresses synchronisation constraints in
terms of guards, path expressions or keywords such as
Ciaran McHale ----
Department of Computer Science, Trinity College, Dublin 2, Ireland. \bi/
Telephone: +353-1-7021539 FAX: +353-1-772204 email: cjmch...@dsg.cs.tcd.ie \/
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.