www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GC interuptable?

reply "chrisj" <a b.c> writes:
Can a low level thread interupt the GC and run ok as long as it doesnt use 
any GC related features? (Only referances memory not from the GC pool and 
such like)

thanks,

chris 
Dec 15 2006
parent reply Sean Kelly <sean f4.ca> writes:
chrisj wrote:
 Can a low level thread interupt the GC and run ok as long as it doesnt use 
 any GC related features? (Only referances memory not from the GC pool and 
 such like)

Are you asking whether it's safe to suspend the GC during a cleanup and then go do something else? If so, then my answer is a very tenative "yes." The GC suspends all threads it knows about during a collection (ie. all instances of std.thread.Thread) so each of these threads is frozen at some point of execution. They could own mutexes, etc. So any operation that may involve shared state information risks deadlocking the app. In short, yes it's possible but you need to be very careful :-) Sean
Dec 15 2006
next sibling parent reply "chrisj" <a b.c> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:elvfpr$1l8j$1 digitaldaemon.com...
 chrisj wrote:
 Can a low level thread interupt the GC and run ok as long as it doesnt 
 use any GC related features? (Only referances memory not from the GC pool 
 and such like)

Are you asking whether it's safe to suspend the GC during a cleanup and then go do something else? If so, then my answer is a very tenative "yes." The GC suspends all threads it knows about during a collection (ie. all instances of std.thread.Thread) so each of these threads is frozen at some point of execution. They could own mutexes, etc. So any operation that may involve shared state information risks deadlocking the app. In short, yes it's possible but you need to be very careful :-)

Say you have a soundcard in/out or somthing like.. which gets called via a callback from the driver or from windows, or even from another application. So the thread is not one actualy created by the D app... can the callback run as long as it doesnt use any features that will affect the GCed memory pool? Actually from what you say above it seems the GC cannot stop a callback from a thread it didnt create.. so the only option would be to make sure such a callback didnt affect the GC? thanks, chris
Dec 16 2006
parent "chrisj" <a b.c> writes:
"chrisj" <a b.c> wrote in message news:em12ih$6lk$1 digitaldaemon.com...
 "Sean Kelly" <sean f4.ca> wrote in message 
 news:elvfpr$1l8j$1 digitaldaemon.com...
 chrisj wrote:
 Can a low level thread interupt the GC and run ok as long as it doesnt 
 use any GC related features? (Only referances memory not from the GC 
 pool and such like)

Are you asking whether it's safe to suspend the GC during a cleanup and then go do something else? If so, then my answer is a very tenative "yes." The GC suspends all threads it knows about during a collection (ie. all instances of std.thread.Thread) so each of these threads is frozen at some point of execution. They could own mutexes, etc. So any operation that may involve shared state information risks deadlocking the app. In short, yes it's possible but you need to be very careful :-)

Say you have a soundcard in/out or somthing like.. which gets called via a callback from the driver or from windows, or even from another application. So the thread is not one actualy created by the D app... can the callback run as long as it doesnt use any features that will affect the GCed memory pool? Actually from what you say above it seems the GC cannot stop a

Sorry should read the "GC cannot stop one that the D RTL didnt create"
 callback from a thread it didnt create.. so the only option would be to 
 make sure such a callback didnt affect the GC?

 thanks,

 chris
 

Dec 16 2006
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:elvfpr$1l8j$1 digitaldaemon.com...

 Are you asking whether it's safe to suspend the GC during a cleanup and 
 then go do something else?  If so, then my answer is a very tenative 
 "yes."  The GC suspends all threads it knows about during a collection 
 (ie. all instances of std.thread.Thread) so each of these threads is 
 frozen at some point of execution.

This also implies another way to have code run while the GC is running -- if you create a thread without using std.thread, the GC won't know about it and won't stop it during the collection. So it can go ahead and run while the GC is doing its thing.
 They could own mutexes, etc.  So any operation that may involve shared 
 state information risks deadlocking the app.  In short, yes it's possible 
 but you need to be very careful :-) 

Dec 16 2006
parent reply "chrisj" <a b.c> writes:
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
news:em12j3$6ls$1 digitaldaemon.com...
 "Sean Kelly" <sean f4.ca> wrote in message 
 news:elvfpr$1l8j$1 digitaldaemon.com...

 Are you asking whether it's safe to suspend the GC during a cleanup and 
 then go do something else?  If so, then my answer is a very tenative 
 "yes."  The GC suspends all threads it knows about during a collection 
 (ie. all instances of std.thread.Thread) so each of these threads is 
 frozen at some point of execution.

This also implies another way to have code run while the GC is running -- if you create a thread without using std.thread, the GC won't know about it and won't stop it during the collection. So it can go ahead and run while the GC is doing its thing.

How hard would it be to stop such a thread buggering up the GC?
Dec 16 2006
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"chrisj" <a b.c> wrote in message news:em12um$6ut$1 digitaldaemon.com...
 This also implies another way to have code run while the GC is running --  
 if you create a thread without using std.thread, the GC won't know about 
 it and won't stop it during the collection.  So it can go ahead and run 
 while the GC is doing its thing.

How hard would it be to stop such a thread buggering up the GC?

I guess just not using the GC? I.e. always using malloc/free, or no dynamic memory allocations at all? And I suppose it'd also be a good idea not to touch memory that was allocated by the GC either. So what you'd have to do is have a non-GC section of your program handled by that thread alone, and it wouldn't touch anything else. Then your main GC'ed program would be able to look at the data held by the non-GC segment in order to update itself. I don't know if this is all right. I don't really have much experience with multithreaded programming, let alone those with non-GC parts.
Dec 16 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
chrisj wrote:
 "Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message 
 news:em12j3$6ls$1 digitaldaemon.com...
 "Sean Kelly" <sean f4.ca> wrote in message 
 news:elvfpr$1l8j$1 digitaldaemon.com...

 Are you asking whether it's safe to suspend the GC during a cleanup and 
 then go do something else?  If so, then my answer is a very tenative 
 "yes."  The GC suspends all threads it knows about during a collection 
 (ie. all instances of std.thread.Thread) so each of these threads is 
 frozen at some point of execution.

if you create a thread without using std.thread, the GC won't know about it and won't stop it during the collection. So it can go ahead and run while the GC is doing its thing.

How hard would it be to stop such a thread buggering up the GC?

It shouldn't be the sole owner of GCed memory or the memory may disappear out from under it. Beyond that, it should be fine. Sean
Dec 16 2006
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Sean Kelly wrote:
 chrisj wrote:
 How hard would it be to stop such a thread buggering up the GC? 

It shouldn't be the sole owner of GCed memory or the memory may disappear out from under it. Beyond that, it should be fine.

Until a moving collector appears on the scene... Since such a collector should be perfectly legal according to the spec, such a thread basically can't use any GC-allocated memory at all without invoking undefined behavior. However as far as it concerns current implementations I'm aware of you're correct; undefined behavior has the unfortunate property that it may mean "it does exactly what you'd expect it to do".
Dec 16 2006