[M3devel] join twice?

[Randy Coleburn]

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).  
 
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).
 
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.
 
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






CONFIDENTIALITY NOTICE:  This email and any attachments are intended solely for the use of the named recipient(s). This e-mail may contain confidential and/or proprietary information of Scientific Research Corporation.  If you are not a named recipient, you are prohibited from making any use of the information in the email and attachments.  If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE:  This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR).  Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require export authorization by the appropriate U.S. Government agency prior to export or transfer.  In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization.  By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.

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