www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Thread pause and resume

reply Steve Teale <steve.teale britseyeview.com> writes:
Earlier versions of D2.x used std.thread which had pause() and resume(). The
later versions use core.thread where these appear to be missing.

Any portable workaround suggestions?
Apr 06 2009
next sibling parent reply grauzone <none example.net> writes:
Steve Teale wrote:

 Earlier versions of D2.x used std.thread which had pause() and resume(). The
later versions use core.thread where these appear to be missing.
 
 Any portable workaround suggestions?


Monitors.
They're even built-in in the language (synchronized statement)
Apr 06 2009
parent Steve Teale <steve.teale britseyeview.com> writes:
grauzone Wrote:


 Steve Teale wrote:

 Earlier versions of D2.x used std.thread which had pause() and resume(). The
later versions use core.thread where these appear to be missing.
 
 Any portable workaround suggestions?


 
 Monitors.
 They're even built-in in the language (synchronized statement)


Unfortunately, Monitors are not documented, and the documentation for classes
says quite specifically that the class property __monitor should not be used in
user code.

I have tried to extract an Object.Monitor interface using this property and to
experiment with its lock and unlock methods, but when I try to call these
methods I just get an access violation. Same if I assume what it returns is a
pointer so struct Monitor, or an instance of interface object.Monitor.

How would you do it?
Apr 06 2009
prev sibling next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Mon, 06 Apr 2009 05:57:24 -0400, Steve Teale  
<steve.teale britseyeview.com> wrote:


 Earlier versions of D2.x used std.thread which had pause() and resume().  
 The later versions use core.thread where these appear to be missing.

 Any portable workaround suggestions?


Also, these functions (if you dig into their implementation) are  
documented as being for debuggers and/or GCs only. Specifically, they can  
not be used for synchronization, etc.
Apr 06 2009
parent reply Steve Teale <steve.teale britseyeview.com> writes:
Robert Jacques Wrote:


 On Mon, 06 Apr 2009 05:57:24 -0400, Steve Teale  
 <steve.teale britseyeview.com> wrote:
 

 Earlier versions of D2.x used std.thread which had pause() and resume().  
 The later versions use core.thread where these appear to be missing.

 Any portable workaround suggestions?


 
 Also, these functions (if you dig into their implementation) are  
 documented as being for debuggers and/or GCs only. Specifically, they can  
 not be used for synchronization, etc.


In 2.06 they were just:

    /**
     * Suspend execution of this thread.
     */
    void pause()
    {
	if (state != TS.RUNNING || SuspendThread(hdl) == 0xFFFFFFFF)
	    error("cannot pause");
    }

    /**
     * Resume execution of this thread.
     */
    void resume()
    {
	if (state != TS.RUNNING || ResumeThread(hdl) == 0xFFFFFFFF)
	    error("cannot resume");
    }

No prohibitions or warnings.

In some code I wrote at that time, I had a worker thread pool. When a thread
had done its job it would mark itself as available then pause. The listener
thread would then resume it or start one that had never been started. I'm
trying to get it running in 2.26. There are functions of the same name there
but they are nested inside SuspendAll and ResumeAll, and so not accessible.
Apr 06 2009
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Steve Teale (steve.teale britseyeview.com)'s article

 In some code I wrote at that time, I had a worker thread pool. When a thread
had done its job it would mark itself as available then


pause. The listener thread would then resume it or start one that had never
been started. I'm trying to get it running in 2.26. There
are functions of the same name there but they are nested inside SuspendAll and
ResumeAll, and so not accessible.

This sounds like a classic producer/consumer case.  I suggest using condition
variables (core.sync.condition with core.sync.mutex).
Apr 06 2009
prev sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Mon, 06 Apr 2009 10:14:41 -0400, Steve Teale  
<steve.teale britseyeview.com> wrote:


 Robert Jacques Wrote:


 On Mon, 06 Apr 2009 05:57:24 -0400, Steve Teale
 <steve.teale britseyeview.com> wrote:


 Earlier versions of D2.x used std.thread which had pause() and  


 resume().

 The later versions use core.thread where these appear to be missing.

 Any portable workaround suggestions?


 Also, these functions (if you dig into their implementation) are
 documented as being for debuggers and/or GCs only. Specifically, they  
 can
 not be used for synchronization, etc.


 In 2.06 they were just:

     /**
      * Suspend execution of this thread.
      */
     void pause()
     {
 	if (state != TS.RUNNING || SuspendThread(hdl) == 0xFFFFFFFF)
 	    error("cannot pause");
     }

     /**
      * Resume execution of this thread.
      */
     void resume()
     {
 	if (state != TS.RUNNING || ResumeThread(hdl) == 0xFFFFFFFF)
 	    error("cannot resume");
     }

 No prohibitions or warnings.


Okay, now follow SuspendThread and ResumeThread and you'll eventually run  
into a (on windows) a function call which is documented on MSDN with a  
bunch of warnings. Admittedly, I traced this a while ago, so pause and  
resume might have been re-purposed away from GC use, but this used to be  
the case.
Apr 06 2009
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Steve Teale (steve.teale britseyeview.com)'s article

 Earlier versions of D2.x used std.thread which had pause() and resume(). The
later versions use


core.thread where these appear to be missing.

 Any portable workaround suggestions?


Use thread synchronization and signaling primitives like the ones
in core.sync.
Apr 06 2009
parent reply Jason House <jason.james.house gmail.com> writes:
Sean Kelly Wrote:


 == Quote from Steve Teale (steve.teale britseyeview.com)'s article

 Earlier versions of D2.x used std.thread which had pause() and resume(). The
later versions use


 core.thread where these appear to be missing.

 Any portable workaround suggestions?


 
 Use thread synchronization and signaling primitives like the ones
 in core.sync.


It's a shame stuff like core.sync doesn't make it into the official changelog
with the dmd releases...
Apr 06 2009
parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Jason House (jason.james.house gmail.com)'s article

 It's a shame stuff like core.sync doesn't make it into the official changelog
with the dmd releases...


That's my fault I suppose.  But since core.sync still appears to be
missing from the import path, the next release can contain the
announcement :-)
Apr 06 2009
prev sibling parent reply Steve Teale <steve.teale britseyeview.com> writes:
Sean Kelly Wrote:


 == Quote from Steve Teale (steve.teale britseyeview.com)'s article

 In some code I wrote at that time, I had a worker thread pool. When a thread
had done its job it would mark itself as available then


 pause. The listener thread would then resume it or start one that had never
been started. I'm trying to get it running in 2.26. There
 are functions of the same name there but they are nested inside SuspendAll and
ResumeAll, and so not accessible.
 
 This sounds like a classic producer/consumer case.  I suggest using condition
 variables (core.sync.condition with core.sync.mutex).


The problem is at the moment, that the D documentation covers the language, and
Phobos - the latter option exposes Object to some extent.

Anything that is in core.* is undocumented and you have to 'rtfsc' - if you can
find it. I can't even find "core.sync" in D files under dmd. Can you point me
in the right direction please.

Thanks Steve
Apr 06 2009
next sibling parent reply Steve Teale <steve.teale britseyeview.com> writes:
Steve Teale Wrote:


 Sean Kelly Wrote:
 

 == Quote from Steve Teale (steve.teale britseyeview.com)'s article

 In some code I wrote at that time, I had a worker thread pool. When a thread
had done its job it would mark itself as available then


 pause. The listener thread would then resume it or start one that had never
been started. I'm trying to get it running in 2.26. There
 are functions of the same name there but they are nested inside SuspendAll and
ResumeAll, and so not accessible.
 
 This sounds like a classic producer/consumer case.  I suggest using condition
 variables (core.sync.condition with core.sync.mutex).


 
 The problem is at the moment, that the D documentation covers the language,
and Phobos - the latter option exposes Object to some extent.
 
 Anything that is in core.* is undocumented and you have to 'rtfsc' - if you
can find it. I can't even find "core.sync" in D files under dmd. Can you point
me in the right direction please.
 
 Thanks Steve
 


As an aside, I realize that Thread.suspend is dodgy, it's been deprecated in

that a particular member function is called only from the instance that it
'belongs' to. Then presumably it could be made safe.
Apr 06 2009
parent reply Fawzi Mohamed <fmohamed mac.com> writes:
On 2009-04-06 20:49:50 +0200, Steve Teale <steve.teale britseyeview.com> said:


 Steve Teale Wrote:
 

 Sean Kelly Wrote:
 

 == Quote from Steve Teale (steve.teale britseyeview.com)'s article

 
 In some code I wrote at that time, I had a worker thread pool. When a 
 thread had done its job it would mark itself as available then


 pause. The listener thread would then resume it or start one that had 
 never been started. I'm trying to get it running in 2.26. There
 are functions of the same name there but they are nested inside 
 SuspendAll and ResumeAll, and so not accessible.
 
 This sounds like a classic producer/consumer case.  I suggest using condition
 variables (core.sync.condition with core.sync.mutex).


 
 The problem is at the moment, that the D documentation covers the 
 language, and Phobos - the latter option exposes Object to some extent.
 
 Anything that is in core.* is undocumented and you have to 'rtfsc' - if 
 you can find it. I can't even find "core.sync" in D files under dmd. 
 Can you point me in the right direction please.
 
 Thanks Steve
 


 As an aside, I realize that Thread.suspend is dodgy, it's been 

 with a way to insist that a particular member function is called only 
 from the instance that it 'belongs' to. Then presumably it could be 
 made safe.


no pause and resume remains a bad idea because it can stop the thread 
in any state, even while it has acquired a lock in any non signal safe 
kernel function, which means that any other thread could block calling 
one of these functions until the thread is released, which if you are 
not very careful might stop the thread that should release it, 
deadlocking the whole program.

Fawzi
Apr 06 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Fawzi Mohamed wrote:

 On 2009-04-06 20:49:50 +0200, Steve Teale <steve.teale britseyeview.com> 
 said:
 

 Steve Teale Wrote:


 Sean Kelly Wrote:


 == Quote from Steve Teale (steve.teale britseyeview.com)'s article

 In some code I wrote at that time, I had a worker thread pool. When 
 a thread had done its job it would mark itself as available then


 pause. The listener thread would then resume it or start one that 
 had never been started. I'm trying to get it running in 2.26. There
 are functions of the same name there but they are nested inside 
 SuspendAll and ResumeAll, and so not accessible.

 This sounds like a classic producer/consumer case.  I suggest using 
 condition
 variables (core.sync.condition with core.sync.mutex).


 The problem is at the moment, that the D documentation covers the 
 language, and Phobos - the latter option exposes Object to some extent.

 Anything that is in core.* is undocumented and you have to 'rtfsc' - 
 if you can find it. I can't even find "core.sync" in D files under 
 dmd. Can you point me in the right direction please.

 Thanks Steve


 As an aside, I realize that Thread.suspend is dodgy, it's been 

 with a way to insist that a particular member function is called only 
 from the instance that it 'belongs' to. Then presumably it could be 
 made safe.


 
 no pause and resume remains a bad idea because [...]


     ^

Insert comma here.


Andrei
Apr 06 2009
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Steve Teale (steve.teale britseyeview.com)'s article

 Sean Kelly Wrote:

 == Quote from Steve Teale (steve.teale britseyeview.com)'s article

 In some code I wrote at that time, I had a worker thread pool. When a thread
had done its job it would mark itself as






available then

 pause. The listener thread would then resume it or start one that had never
been started. I'm trying to get it running in




2.26. There

 are functions of the same name there but they are nested inside SuspendAll and
ResumeAll, and so not accessible.

 This sounds like a classic producer/consumer case.  I suggest using condition
 variables (core.sync.condition with core.sync.mutex).


 The problem is at the moment, that the D documentation covers the language,
and Phobos - the latter option exposes Object


to some extent.

 Anything that is in core.* is undocumented and you have to 'rtfsc' - if you
can find it. I can't even find "core.sync" in D files


under dmd. Can you point me in the right direction please.

Darnit... core.sync is supposed to be in src/druntime/import/core/sync, but it
isn't
there for some reason.  I thought this issue had been fixed.  Well, in theory
it should
be there, and I'm working on getting the docs integrated with the Phobos docs. 
They're
already generated by the build...
Apr 06 2009
parent Steve Teale <steve.teale britseyeview.com> writes:
Sean Kelly Wrote:


 == Quote from Steve Teale (steve.teale britseyeview.com)'s article

 Sean Kelly Wrote:

 == Quote from Steve Teale (steve.teale britseyeview.com)'s article

 In some code I wrote at that time, I had a worker thread pool. When a thread
had done its job it would mark itself as






 available then

 pause. The listener thread would then resume it or start one that had never
been started. I'm trying to get it running in




 2.26. There

 are functions of the same name there but they are nested inside SuspendAll and
ResumeAll, and so not accessible.

 This sounds like a classic producer/consumer case.  I suggest using condition
 variables (core.sync.condition with core.sync.mutex).


 The problem is at the moment, that the D documentation covers the language,
and Phobos - the latter option exposes Object


 to some extent.

 Anything that is in core.* is undocumented and you have to 'rtfsc' - if you
can find it. I can't even find "core.sync" in D files


 under dmd. Can you point me in the right direction please.
 
 Darnit... core.sync is supposed to be in src/druntime/import/core/sync, but it
isn't
 there for some reason.  I thought this issue had been fixed.  Well, in theory
it should
 be there, and I'm working on getting the docs integrated with the Phobos docs.
 They're
 already generated by the build...


A straight answer to a straight question. Thanks Sean. I'll change my code to
let used threads die, and start new ones until I see this stuff.
Apr 06 2009