(j3.2006) LOCK/UNLOCK question

[Malcolm Cohen]

Hi Aleks,

> Firstly, why don't I ever see Dick's original messages? Is he not on the
> J3 list anymore? My inbox has no messages from Dick...
>   
I guess he is being caught by your spam filter or something.  I'm 
getting all of them, and he is only sending them to the J3 list + Nick 
Maclaren.
>   
>> Well, we only needs words to define the cases we make valid; I believe
>> that, as long as we leave the "no-side-effects" rule
>>     
> OK...I have always found the "no-side-effects" clauses somewhat
> ambiguous and difficult to exactly pin-point, but as long as it is clear
> what is legal and not I am fine.
>
> Can someone please point me to the actual side-effect words in 09-007r1?
>   
[141:3-8]

I used to be able to find this stuff much faster (and more reliably) 
until someone moved it all around.
> "Side-effect" only seems to appear in notes so there must be other
> wording...
>   
Actually, side-effects are ok, it is only when you have a side-effect 
that affects something in the same statement (like two side-effects 
conflicting, or one side-effect changing a variable that appears 
elsewhere in the expression) that is bad.

Otherwise side-effects are ok.
>   
>> intact we already
>> have the words for what LOCK/UNLOCK do.
>>     
> I would propose that the only legal thing be a paired LOCK/UNLOCK on the
> same lock within the multiple procedures. Otherwise it sounds to me like
> an actual visible) side-effect, which should not be allowed.
Unpaired ones are fine by the "side-effect" rule, as long as you don't 
have conflicting ones.

So a LOCK and an UNLOCK for the same variable (but from different 
function references) would be invalid,
but a LOCK for one variable and an UNLOCK for a different variable would 
be ok.
> Sounds "safe" enough, although I will continue to grudge about CRITICAL(lock)
> being rejected...
>
> Bill also mentioned STOP and SYNC MEMORY. The first one already seems
> allowed to me. If one of the functions calls STOP, clearly no other can
> also "cause execution of" STOP.
Good point.


Cheers,
-- 
..............................Malcolm Cohen, Nihon NAG, Tokyo.