[M3devel] join twice?

Tue Nov 3 17:09:03 CET 2009

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/ca3740f9/attachment-0002.html>