[M3devel] join twice?

[Tony Hosking]

This sounds like a great plan.  To be honest, checking the multiple  
join error is not hard to do in any implementation.

On 3 Nov 2009, at 11:31, Randy Coleburn wrote:

> I guess I will need to go back and look at Nelson again, but is it  
> possible that one of the subsequent editions of SPwM3 added this  
> prohibition against multiple joins?  I seem to recall that some of  
> the interfaces got a rework and were published after the first  
> printing of the book, but that the community adopted these as a  
> whole to be "the spec" for M3.  Maybe the comment in Thread.i3  
> became law at that point?
>
> In any event, I still argue that it doesn't make sense to do  
> multiple joins and I agree with Mika that it is often a symptom of  
> bad programming and we want the language to help us write less buggy  
> code.
>
> So, I would vote that we don't make any changes to permit multiple  
> joins.  It may be true that the current implementation does not  
> enforce the prohibition against multiple joins on all platforms  
> simply because it was the easiest thing to do at the time.  In this  
> case, I argue that the implementation is not being totally faithful  
> to the specification; but if the programmer heeds the spec, then  
> there is no consequence to the implementation's lack of enforcement.
>
> Bottom line:  Let's not devolve from the noble position of doing the  
> right thing simply because the implementation has been less than  
> faithful.  Keep the comment and the prohibition and work toward  
> improving the implementation over time to be faithful to the  
> specification.  (Does that make me a "practical idealist"?)
>
> Regards,
> Randy Coleburn
>
> >>> Tony Hosking <hosking at cs.purdue.edu> 11/3/2009 11:09 AM >>>
> On 3 Nov 2009, at 10:49, Randy Coleburn wrote:
>
>> Understand the part about being "torn".
>>
>> I for one, have always programmed with the understanding that the  
>> comment was enforced.
>>
>> IMO:  If one needs to pass the result of a thread outside the  
>> thread's context, one should use an explicit mechanism or data  
>> structure (e.g., conditions, object data fields, etc.).
>>
>> If multiple threads need to wait for a thread to finish, that is  
>> the whole concept of a rendevous (see the "Little Book of  
>> Semaphores" you referenced earlier).
>
> Agreed.
>
>>  If programmers must depend on multiple joins, when is it ever safe  
>> for the underlying infrastructure to "forget about" the dead thread  
>> and its return value(s), if any?  At what point has it been "too  
>> long" for you to query about a dead thread's status/return values  
>> (millisecs, minutes, hours, days, weeks -- for long-running  
>> programs this can be problematic).
>
> We can forget about the dead thread only when it is GC'd.  No-one  
> can call Join without a reference to it.
>
>>  I would argue that it is better for the programmer to be explicit  
>> in such matters.  It is easy enough to implement given the  
>> capabilities of the language, and indeed, I've done so many times.
>
> Agreed.  The odd thing is just that the old "reference" user-level  
> threads implementation never did the check, and permitted multiple  
> joins.  And the threads spec in SPwM3 is silent on the issue.
>
>> Regards,
>> Randy Coleburn
>>
>> >>> Jay K <jay.krell at cornell.edu> 11/3/2009 10:04 AM >>>
>> To me..with a Win32 background..join means "wait for thread to  
>> finish".
>> And there is a separate action "get thread result".
>> You could consider these one merged operation "wait for thread to  
>> finish and get its result".
>> In either case, it is reasonable to allow it multiple times.
>> Waiting for a thread to finish that has already finished is just  
>> fast.
>> Getting a thread result that you already got is also easy albeit  
>> usually unnecessary.
>>
>> Now, if the operation is "wait for thread to finish, get its  
>> result, and lose track of its result",
>> that isn't idempotent.
>>
>> I'm torn. The existing implementations all either support multiple  
>> join or have to go out of
>> their way to prevent it. Yet Thread.i3 has been commented so  
>> presumably forever.
>>
>>  - Jay
>>
>>
>> Date: Tue, 3 Nov 2009 09:36:23 -0500
>> From: rcoleburn at scires.com
>> To: m3devel at elegosoft.com
>> Subject: Re: [M3devel] join twice?
>>
>> I think the comment in the code is correct.
>>
>> Semantically, it doesn't make sense to join a thread more than  
>> once.  Join is the compliment to Fork.  With fork, one thread  
>> becomes two.  With Join, two threads become one.  After they've  
>> become one, the 2nd thread is no more, so you can't join to it  
>> anymore.
>>
>> IMO, the implementation should enforce this behavior.  What would  
>> be the "benefit" of allowing more than one join?  What does it  
>> "mean" to join a "dead thread"?
>>
>> Regards,
>> Randy Coleburn
>>
>> >>> Tony Hosking <hosking at cs.purdue.edu> 11/2/2009 11:54 PM >>>
>> OK, sure.  Fair enough.
>>
>> On 2 Nov 2009, at 16:43, Jay K wrote:
>>
>>  > (Whether the implementation actually prohibits it or not is an  
>> implementation decision.)
>>
>> Tony, I'm sympathetic to the smaller version but I think it is wrong.
>> "It is a checked runtime error to call this more than once for any t"
>> is a much different/stronger statement than e.g.
>> "it is implementation defined what happens if you call join more  
>> than once for any t".
>> The printed Reactor 4.1 docs have the same comment as current  
>> Thread.i3.
>>
>> You know, ideally if I write:
>> Thread.Join(t);
>> Thread.Join(t);
>>
>> and it works today on any system, it will continue to work on all  
>> systems.
>> I think "implementation defined" is something Modula-3 tries to  
>> have less of.
>>
>> On the other hand, I think if we foresee it to work trivially on all
>> forseeable implementations, we can change the interface by removing  
>> the comment.
>> Win32 WaitForSingleObject(thread, INFINITE) is allowed multiple  
>> times, though
>> that isn't the current implementation.
>>
>>  - Jay
>>
>> From: hosking at cs.purdue.edu
>> To: jay.krell at cornell.edu
>> Date: Mon, 2 Nov 2009 12:59:36 -0500
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] join twice?
>>
>> I don't know that there ever was a mandate that join can only be  
>> called once on a given thread.  But, given that pthread_join is  
>> undefined when called more than once on the same thread we probably  
>> want to retain the comment.  (Whether the implementation actually  
>> prohibits it or not is an implementation decision.)  The point is  
>> that we should be free to give the error in some later  
>> implementation, so as to not to restrict what semantics the  
>> implementation must support.
>>
>> Antony Hosking | Associate Professor | Computer Science | Purdue  
>> University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>>
>>
>>
>>
>> On 2 Nov 2009, at 10:11, Jay K wrote:
>>
>> Thread.i3:
>>
>>
>> PROCEDURE Join(t: T): REFANY;
>> (* Wait until "t" has terminated and return its result. It is a
>>    checked runtime error to call this more than once for any "t". *)
>>
>>
>> ThreadWin32.m3:
>>
>>
>> PROCEDURE Join(t: T): REFANY =
>>   VAR res: REFANY;
>>   BEGIN
>>     LOCK t DO
>>       IF t.joined THEN Die(ThisLine(), "attempt to join with thread  
>> twice"); END;
>>       WHILE NOT t.completed DO Wait(t, t.join) END;
>>       res := t.result;
>>       t.result := NIL;
>>       t.joined := TRUE;
>>       t.join := NIL;
>>     END;
>>     RETURN res;
>>   END Join;
>>
>> PROCEDURE AlertJoin(t: T): REFANY RAISES {Alerted} = similar
>>
>>
>> ThreadPThread.m3:
>>
>>
>> PROCEDURE Join (t: T): REFANY =
>>   BEGIN
>>     LOCK t DO
>>       WHILE NOT t.completed DO Wait(t, t.join) END;
>>     END;
>>     RETURN t.result;
>>   END Join;
>>
>> PROCEDURE AlertJoin (t: T): REFANY RAISES {Alerted} = similar
>>
>>
>> Should we just loosen the comment and go with the simpler pthread  
>> version?
>> I'd like Win32 and pthread to be more similar where possible, to  
>> ease maintenance.
>>
>>
>>  - Jay
>>
>>
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091103/ac9a6cee/attachment-0002.html>