Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!dimacs.rutgers.edu!aramis.rutgers.edu!paul.rutgers.edu!njin!uupsi!mstr!mstr!jcm
From: jcm@mstr.hgc.edu (James McKim)
Newsgroups: comp.lang.eiffel
Subject: Re: Functions without side effects (was Old confusion)
Message-ID: <1991Jun10.145524.29305@mstr.hgc.edu>
Date: 10 Jun 91 14:55:24 GMT
References: <1991May30.141218.3446@mstr.hgc.edu> <6135@goanna.cs.rmit.oz.au>
Sender: Usenet@mstr.hgc.edu (Action News Central)
Reply-To: jcm@mstr.hgc.edu (James McKim)
Organization: The Hartford Graduate Center, Hartford CT.
Lines: 50
Nntp-Posting-Host: sc3.hgc.edu

In article <6135@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>In article <1991Jun5.140023.4614@mstr.hgc.edu>, jcm@mstr.hgc.edu (James McKim) writes:
>> In article <1991Jun4.041233.19046@runx.oz.au> chrisv@runx.oz.au (Chris Velevitch) writes:
>> >Testing the result of 'test_and_set' routine is the same as testing
>> >'got_resource'. So 'test_and_set' should be a procedure and the result
>> >available through some other feature, in this case 'got_resource'.
>
>> Hallellujah and welcome soul brother!
>
>If you two "soul brothers" will have the kindness to label your programs
>in bright red letters "DANGER -- DO NOT USE" I will much appreciate it.

Now, now, no need to get testy.

>This separation between setting a flag and accessing it is a *disaster*
>in multi-threaded systems. 

No one disagrees that 'test_and_set' must be atomic. The only question is
how to inform the client whether 'test_and_set' succeeded. Is it better
to return a value directly or set an attribute that the client may check?

Whoops! OK I think I see the light. The problem occurs if I call
test_and_set and got_resource is set to True, but before I get around
to checking it, somebody else calls test_and_set and since I have
the resource (but don't know it yet), got_resource is set to False.
This is indeed a compelling reason for test_and_set to both return
a value and have the side effect of setting free to False and I
don't see any reasonably easy way around it. Thanks
for exciting the right set of neurons. :-)

>
>If you don't like procedures that return a status value, add an extra
>"status" argument to the interface.

Well, conceptually this is still a function with side effects. The return
value is simply in a different place. I still argue that the default
should be to avoid such things, but there _are_ counterexamples.

>Should you ever intend to dull the wits of a young man and to
>incapacitate his brains for any kind of thought whatever, then
>you cannot do better than give him Hegel to read.  -- Schopenhauer.

-- Jim




*------------------------------------------------------------------------------*
Jim McKim  (203)-548-2458   _Give_ people fish and they eat for a day.  
Internet:  jcm@mstr.hgc.edu _Teach_ people to fish and they eat for a lifetime.