www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.thread

reply Mike Parker <aldacron71 yahoo.com> writes:
Two points about std.thread:

1) Considering that the thread class has a public static yield() method, 
it would be nice to see a similar sleep method that accepts a 
milliscecond argument. There's no way that I can see to sleep in the 
current thread without bringing in OS-specific functions.

2) The 2 wait methods are misnamed, IMO. The first reaction I had to 
seeing them was that they are sleep methods, but of course they are not. 
I think a more appropriate name would be 'join'.


silly that Thread.yield calls Sleep(0) on Windows, but to sleep for a 
fixed amount of time one must import std.c.windows.windows and call 
Sleep(X) onself.
Feb 12 2005
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Mike Parker wrote:

 Two points about std.thread:
 
 1) Considering that the thread class has a public static yield() method, 
 it would be nice to see a similar sleep method that accepts a 
 milliscecond argument. There's no way that I can see to sleep in the 
 current thread without bringing in OS-specific functions.
 
 2) The 2 wait methods are misnamed, IMO. The first reaction I had to 
 seeing them was that they are sleep methods, but of course they are not. 
 I think a more appropriate name would be 'join'.


I've addressed both of these in Ares.  I've been kind of MIA for the 
past month or two, but I expect to have time to begin working on it 
again soon.  The next big thing I was planning to work on was a POSIX 
threading implementation.



 silly that Thread.yield calls Sleep(0) on Windows, but to sleep for a 
 fixed amount of time one must import std.c.windows.windows and call 
 Sleep(X) onself.


Small thing.  I read a while back that Sleep(0) doesn't actually yield 
as it should and that you've got to use Sleep(1) instead.  I haven't 
verified this myself, but I'm using Sleep(1) in my threading implementation.


Sean
Feb 15 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:cuusj6$2fnd$1 digitaldaemon.com...

 Mike Parker wrote:

 Two points about std.thread:

 1) Considering that the thread class has a public static yield() method, 
 it would be nice to see a similar sleep method that accepts a 
 milliscecond argument. There's no way that I can see to sleep in the 
 current thread without bringing in OS-specific functions.




I agree std.thread should get a sleep function. I've wondered why it wasn't 
there myself. How about someone add sleep to std.thread and send it to 
Walter (with modified phobos.html for documentation)?


 2) The 2 wait methods are misnamed, IMO. The first reaction I had to 
 seeing them was that they are sleep methods, but of course they are not. 
 I think a more appropriate name would be 'join'.




Even though join is the POSIX name I've never been a big fan of the word 
"join" to describe what join does since technically you are waiting for a 
thread to finish - you aren't "joining" threads. When I first learned about 
join I thought it somehow took whatever that thread was doing and did it in 
the same thread as the current thread, which is nonsense. By analogy, if you 
are talking to a friend and you say "I'll join you at the party" you don't 
mean that you'll wait until the party is over before seeing them. Anyway, 
that doesn't mean "wait" is the perfect name either. Maybe just plain old 
"finish" would do. The doc would explain the "finish" means "wait for 
finish" and not cancel or terminate or something that kills the thread 
immediately.

I wonder if wait should use default parameters. It was probably written back 
when defaults didn't exist:
  void finish(uint timeout = uint.max)
  { [snip]
    dw = WaitForSingleObject(hdl, timeout);
  }
 alias finish wait;


 I've addressed both of these in Ares.  I've been kind of MIA for the past 
 month or two, but I expect to have time to begin working on it again soon. 
 The next big thing I was planning to work on was a POSIX threading 
 implementation.


Can parts of Ares be rolled into phobos?



 that Thread.yield calls Sleep(0) on Windows, but to sleep for a fixed 
 amount of time one must import std.c.windows.windows and call Sleep(X) 
 onself.


 Small thing.  I read a while back that Sleep(0) doesn't actually yield as 
 it should and that you've got to use Sleep(1) instead.  I haven't verified 
 this myself, but I'm using Sleep(1) in my threading implementation.


I believe Sleep(0) yields if there are any threads that are waiting. If 
there aren't any threads waiting Sleep(0) returns immediately. Sleep(1) will 
always sleep for 1 millisecond even if there isn't anything else waiting. So 
I think Sleep(0) would make a better yield() implementation.
Feb 16 2005
next sibling parent reply Daan Oosterveld <daan.oosterveld home.nl> writes:
Join: You join the two execution paths of the threads. If that means 
waiting for the thread it will do that. If the thread in question has 
already stopped executing then join does not wait.

 From the man page:
The pthread_join() function suspends execution of the calling thread 
until the target thread terminates unless the target thread has already 
terminated.

Finish implies that the thread will actively stop the execution of 
another thread. Finishing of the thread ;) If you ask someone to join 
you at a party the 'someone' has a choice of ignoring your request.

I like .join() ;)

Daan.


 
 Even though join is the POSIX name I've never been a big fan of the word 
 "join" to describe what join does since technically you are waiting for a 
 thread to finish - you aren't "joining" threads. When I first learned about 
 join I thought it somehow took whatever that thread was doing and did it in 
 the same thread as the current thread, which is nonsense. By analogy, if you 
 are talking to a friend and you say "I'll join you at the party" you don't 
 mean that you'll wait until the party is over before seeing them. Anyway, 
 that doesn't mean "wait" is the perfect name either. Maybe just plain old 
 "finish" would do. The doc would explain the "finish" means "wait for 
 finish" and not cancel or terminate or something that kills the thread 
 immediately.
Feb 16 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Daan Oosterveld" <daan.oosterveld home.nl> wrote in message 
news:cuvpot$eel$1 digitaldaemon.com...

 Join: You join the two execution paths of the threads. If that means 
 waiting for the thread it will do that. If the thread in question has 
 already stopped executing then join does not wait.

 From the man page:
 The pthread_join() function suspends execution of the calling thread until 
 the target thread terminates unless the target thread has already 
 terminated.


I argue most people who don't know the POSIX meaning of join would not use 
"join" to describe what join does.


 Finish implies that the thread will actively stop the execution of another 
 thread. Finishing of the thread ;) If you ask someone to join you at a 
 party the 'someone' has a choice of ignoring your request.


I disagree that "finish" means stop immediately. Words like "stop" or 
"interrupt" or "kill" or "terminate" to me means stop immediately. "Finish" 
means the task was actually done and not interrupted. For example if someone 
asks "did you finish the task?" a reasonable answer would be "no I was 
stopped before I could finish" or "yes, I finished it" or "no, I was 
killed". :-)


 I like .join() ;)


Yup. That's fine. Plenty of people do. But I think D can do better.


 Daan.


 Even though join is the POSIX name I've never been a big fan of the word 
 "join" to describe what join does since technically you are waiting for a 
 thread to finish - you aren't "joining" threads. When I first learned 
 about join I thought it somehow took whatever that thread was doing and 
 did it in the same thread as the current thread, which is nonsense. By 
 analogy, if you are talking to a friend and you say "I'll join you at the 
 party" you don't mean that you'll wait until the party is over before 
 seeing them. Anyway, that doesn't mean "wait" is the perfect name either. 
 Maybe just plain old "finish" would do. The doc would explain the 
 "finish" means "wait for finish" and not cancel or terminate or something 
 that kills the thread immediately.
Feb 16 2005
next sibling parent reply Daan Oosterveld <daan.oosterveld home.nl> writes:
 
 I argue most people who don't know the POSIX meaning of join would not use 
 "join" to describe what join does.
 


If no one whould know what join or finish means in a thread context 
maybee the function should be:

Thread t,targetThread;
t.suspendExecutionOfTheCallingThreadUntilTheTargetThreadTerminatesUnless 
TheTargetThreadHasAlreadyTerminated( targetThread );

:-D

Most functions are not obvious if you don't know the context. Unless you 
like typing functions like above ;) Join has a different name because it 
acts in a different context. If all functions would be alike the source 
would become unreadable.

If people are using threads they should be carefull. We could asume 
users are familiar with threads know which function to pick. If not 
point to the pthread documentation. (most widely used interface to 
threads) It makes sense to me that std.thread would mirror the POSIX 
interface.

Daan
Feb 16 2005
parent pragma <pragma_member pathlink.com> writes:
In article <cuvre0$ge8$1 digitaldaemon.com>, Daan Oosterveld says...

If no one whould know what join or finish means in a thread context 
maybee the function should be:

Thread t,targetThread;
t.suspendExecutionOfTheCallingThreadUntilTheTargetThreadTerminatesUnless 
TheTargetThreadHasAlreadyTerminated( targetThread );


LOL! Did a laywer get a hold of your code?

Provided a programmer types that in correctly, they pretty much waive the right
to claim that the function did anything undocumented.

- EricAnderton at yahoo
Feb 16 2005
prev sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Ben Hinkle wrote:
  > I argue most people who don't know the POSIX meaning of join would 
not use

 "join" to describe what join does.


Perhaps, but it's not just used in the POSIX world. I've never worked 
with pthreads, never done any POSIX programming at all outside of a 
couple of tutorials on *nix programming. In Java, the Thread class has 3 
methods names join. I have also seen the same functionality names join 
in a few libraries that provide crossplatform threading in one form or 
another (such as the Torque game engine). I suggested it because it 
seems to be fairly common, if not standard. This is the first time I've 
seen 'wait' used in this context. Now that I know what it does, it's no 
big deal. But I do think it's a bit offputting for someone who is 
looking for a join method. 'wait' doesn't jump out and say 'use me 
instead' without digging around in the docs or the source, at least to me.
Feb 16 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Mike Parker" <aldacron71 yahoo.com> wrote in message 
news:cuvsnd$hqn$1 digitaldaemon.com...

 Ben Hinkle wrote:
  > I argue most people who don't know the POSIX meaning of join would not 
 use

 "join" to describe what join does.


 Perhaps, but it's not just used in the POSIX world. I've never worked with 
 pthreads, never done any POSIX programming at all outside of a couple of 
 tutorials on *nix programming. In Java, the Thread class has 3 methods 
 names join. I have also seen the same functionality names join in a few 
 libraries that provide crossplatform threading in one form or another 
 (such as the Torque game engine). I suggested it because it seems to be 
 fairly common, if not standard. This is the first time I've seen 'wait' 
 used in this context. Now that I know what it does, it's no big deal. But 
 I do think it's a bit offputting for someone who is looking for a join 
 method. 'wait' doesn't jump out and say 'use me instead' without digging 
 around in the docs or the source, at least to me.


I don't know the history of POSIX but wait() in the unix world is used to 
wait for child processes and probably that's why POSIX couldn't use wait(). 
The win32 API is WaitForSingleObject. I'd guess Java went with join because 
Sun is a unix vendor and several Java-ism look like they came from Unix plus 
Java uses "wait" for waiting on a lock - which is probably a more common use 
of waiting than waiting for a thread to finish.

FWIW, for a similar behavior MATLAB uses "waitfor".
Feb 16 2005
prev sibling next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 16 Feb 2005 10:21:48 -0500, Ben Hinkle <bhinkle mathworks.com>  
wrote:

 "Sean Kelly" <sean f4.ca> wrote in message
 news:cuusj6$2fnd$1 digitaldaemon.com...

 Mike Parker wrote:

 2) The 2 wait methods are misnamed, IMO. The first reaction I had to
 seeing them was that they are sleep methods, but of course they are  
 not.
 I think a more appropriate name would be 'join'.




 Even though join is the POSIX name I've never been a big fan of the word
 "join" to describe what join does since technically you are waiting for a
 thread to finish - you aren't "joining" threads. When I first learned  
 about
 join I thought it somehow took whatever that thread was doing and did it  
 in
 the same thread as the current thread, which is nonsense. By analogy, if  
 you
 are talking to a friend and you say "I'll join you at the party" you  
 don't
 mean that you'll wait until the party is over before seeing them. Anyway,
 that doesn't mean "wait" is the perfect name either. Maybe just plain old
 "finish" would do. The doc would explain the "finish" means "wait for
 finish" and not cancel or terminate or something that kills the thread
 immediately.


I think it should be called "waitFor".

As in when you say to a friend "I'll wait for you here", then you do  
nothing till they're done doing what they're doing.

Regan
Feb 16 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
 I think it should be called "waitFor".
 
 As in when you say to a friend "I'll wait for you here", then you do  
 nothing till they're done doing what they're doing.


I think we should use what is the Industry Standard.

That is, if we can agree on what _that_ is. :-)

For example, if we think that the day D takes over the "C world"
(let's call it D-day!), and if we assume Linux prevails by
then -- then it would look odd if we use the same concepts
with words that are slightly different.
Feb 16 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 17 Feb 2005 00:22:04 +0200, Georg Wrede <georg.wrede nospam.org>  
wrote:

 I think it should be called "waitFor".
  As in when you say to a friend "I'll wait for you here", then you do   
 nothing till they're done doing what they're doing.


 I think we should use what is the Industry Standard.

 That is, if we can agree on what _that_ is. :-)


Exactly, suggesting there *isn't* an "Industry Standard".

Besides if the "Industry Standard" makes no sense then I say "improve on  
it", if we didn't do that sort of thing we'd still be living in caves  
using rocks for pillows.


 For example, if we think that the day D takes over the "C world"
 (let's call it D-day!), and if we assume Linux prevails by
 then -- then it would look odd if we use the same concepts
 with words that are slightly different.


Bah.. linux will look odd for using archaic and nonsensical terms when  
compared next to D's shining example of perfection!

All IMO of course.

Regan
Feb 16 2005
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
In article <cuvoee$ctt$1 digitaldaemon.com>, Ben Hinkle says...

Can parts of Ares be rolled into phobos?


Not without a bit of work.  I've made no effort to maintain interface
consistency between Ares classes and their Phobos counterparts (if Phobos
counterparts exist).  In the case of the Thread class, the current Phobos
interface exposes some features for gc use that I think would be cleaner handled
another way (ie. the way they're handled in Ares).


 Small thing.  I read a while back that Sleep(0) doesn't actually yield as 
 it should and that you've got to use Sleep(1) instead.  I haven't verified 
 this myself, but I'm using Sleep(1) in my threading implementation.


I believe Sleep(0) yields if there are any threads that are waiting. If 
there aren't any threads waiting Sleep(0) returns immediately. Sleep(1) will 
always sleep for 1 millisecond even if there isn't anything else waiting. So 
I think Sleep(0) would make a better yield() implementation.


That could very well be the case.  I read the bit about Sleep(0) not working as
advertised either in the Boost listserv or on comp.programming.threads, but
either way the information could be out of date.  Still, I'm keeping the current
implementation in Ares until I verify.


Sean
Feb 16 2005
prev sibling parent reply Kris <Kris_member pathlink.com> writes:
In article <cuvoee$ctt$1 digitaldaemon.com>, Ben Hinkle says...

Can parts of Ares be rolled into phobos?


For those who weren't around at the time:

Ares is intended to be a much better 'standard' runtime library for D, and the
notion was "endorsed" by Walter. one of the primary goals is to have a "backward
compatability" area (a set of packages) to support Phobos-based code, with
little or no changes to said code. That is, Phobos would be subsumed by Ares.
Given that, I don't see much value in rolling Ares functionality back into
Phobos. 

As I recall, there had been a suggestion to hold back until we all had Sean's
foundation to work upon. I understand we are nearly at that point, so perhaps
it's time to stoke up the fires again? There was a pretty good layout for a set
of packages.

Ares topics are over here: http://dsource.org/forums/viewforum.php?f=31
Feb 16 2005
parent Sean Kelly <sean f4.ca> writes:
In article <cv0mob$1jh3$1 digitaldaemon.com>, Kris says...

As I recall, there had been a suggestion to hold back until we all had Sean's
foundation to work upon. I understand we are nearly at that point, so perhaps
it's time to stoke up the fires again? There was a pretty good layout for a set
of packages.


It would be nice.  I'm getting a bit of free time again, and the basic framework
is almost all in place.  I need to do a bit more work on the Thread class and it
should be just about there.  There is one sticky issue within the GC code that I
have yet to resolve so if anyone is feeling ambitious I'd love a fresh set of
eyes too look at it.


Sean
Feb 16 2005
prev sibling parent Ben Hinkle <Ben_member pathlink.com> writes:
In article <culdcj$22sq$1 digitaldaemon.com>, Mike Parker says...

Two points about std.thread:

1) Considering that the thread class has a public static yield() method, 
it would be nice to see a similar sleep method that accepts a 
milliscecond argument. There's no way that I can see to sleep in the 
current thread without bringing in OS-specific functions.

2) The 2 wait methods are misnamed, IMO. The first reaction I had to 
seeing them was that they are sleep methods, but of course they are not. 
I think a more appropriate name would be 'join'.


silly that Thread.yield calls Sleep(0) on Windows, but to sleep for a 
fixed amount of time one must import std.c.windows.windows and call 
Sleep(X) onself.


I thought of a third thing:
3) do something about wait(uint milleseconds) on Linux. Currently the body is
commented out and it just calls wait(). Does anyone know how to code that up?
Feb 16 2005