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

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

"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

"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 :-)

"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
> 

"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?

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

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

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

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