www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How to ensure a thread cannot be blocked by the GC?

reply "ponce" <contact gam3sfrommars.fr> writes:
I have a DLL written in D that gets called by two different 
threads, created by a non-D host program (audio plugin). I did 
not create those threads, but my understanding is that they get 
"attached" to the D runtime.

Thread A is a real-time callback and should not ever block.  nogc 
seems perfect for this.

Thread B and it's impractical to make it  nogc.

How to ensure that a collection triggered by thread B never stop 
thread A in stop the world collections?
Dec 03 2014
next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Wednesday, 3 December 2014 at 22:53:48 UTC, ponce wrote:

 I have a DLL written in D that gets called by two different 
 threads, created by a non-D host program (audio plugin). I did 
 not create those threads, but my understanding is that they get 
 "attached" to the D runtime.

 Thread A is a real-time callback and should not ever block. 
  nogc seems perfect for this.

 Thread B and it's impractical to make it  nogc.

 How to ensure that a collection triggered by thread B never 
 stop thread A in stop the world collections?


Correction:


 Thread B isn't real-time, allocates, and it's impractical to 
 make it  nogc.
Dec 03 2014
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 3 December 2014 at 22:53:48 UTC, ponce wrote:

 I have a DLL written in D that gets called by two different 
 threads, created by a non-D host program (audio plugin). I did 
 not create those threads, but my understanding is that they get 
 "attached" to the D runtime.

 Thread A is a real-time callback and should not ever block. 
  nogc seems perfect for this.

 Thread B and it's impractical to make it  nogc.

 How to ensure that a collection triggered by thread B never 
 stop thread A in stop the world collections?


I assume you are referring to Windows and I have no good answer 
for you. Could it not vary between implementations or is it 
language defined? However, a real time thread ought to be 
specified by the OS as being non-interruptable (but with a 
timeout). Otherwise it should not be labeled as realtime… 
AudioUnits on OS-X are called with realtime priority.

IRRC the D GC uses SIGUSR1 on unix, so there you should be able 
to specify a signal mask to tell the OS whether to block the 
thread on collection or not.
Dec 03 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 4 December 2014 at 00:27:49 UTC, Ola Fosheim Grøstad 
wrote:

 I assume you are referring to Windows and I have no good answer


Btw, I found this page to be a nice starting point and generally 
a good read for writing portable code:

http://msdn.microsoft.com/en-us/library/ms811896.aspx
Dec 03 2014
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 4 December 2014 at 00:27:49 UTC, Ola Fosheim Grøstad 
wrote:

 IRRC the D GC uses SIGUSR1 on unix, so there you should be able


Hmmm, I have no idea why I wrote this. According to the code for 
the runtime it only suspends threads that inherit from Thread? GC 
fullcollect calls thread_suspendAll which traverses a linked list 
of Threads.

So I suppose none of your threads are suspended unless you 
suspend it with Thread on call_back entry? But why suspend a 
 nogc thread?

https://github.com/D-Programming-Language/druntime/blob/master/src/core/thread.d#L2501

https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L2479
Dec 03 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 4 December 2014 at 01:36:13 UTC, Ola Fosheim Grøstad 
wrote:

 So I suppose none of your threads are suspended unless you 
 suspend it with Thread on call_back entry? But why suspend a 
  nogc thread?


What a mess of incorrect recollection and typos (it is late, 3AM 
:-P): I  meant to say that I suppose none of your threads are 
suspended unless you register it as a Thread before the call_back 
entry. But if you do it on the call_back entry point by 
registering a fake Thread object you must ensure that you are not 
already in a collection cycle before continuing…

Seems to me that there should either be better documentation of 
GC behaviour or some extra functionality for controlling GC 
interference with threads and Threads. I also find this 
confusing… There is a lot of policy making in D's runtime and 
standard library.
Dec 03 2014
parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Thursday, 4 December 2014 at 02:01:26 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 4 December 2014 at 01:36:13 UTC, Ola Fosheim 
 Grøstad wrote:

 So I suppose none of your threads are suspended unless you 
 suspend it with Thread on call_back entry? But why suspend a 
  nogc thread?


 What a mess of incorrect recollection and typos (it is late, 
 3AM :-P): I  meant to say that I suppose none of your threads 
 are suspended unless you register it as a Thread


Thanks Ola & Jacob.
In fact I was registering them both with 
core.sys.windows.dll.dll_thread_attach() when callbacked with 
DLL_THREAD_ATTACH, but I see now that I should instead register 
to the runtime only the interruptible thread.

Made-up problem!
Dec 04 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 4 December 2014 at 08:18:23 UTC, ponce wrote:

 In fact I was registering them both with 
 core.sys.windows.dll.dll_thread_attach() when callbacked with 
 DLL_THREAD_ATTACH, but I see now that I should instead register 
 to the runtime only the interruptible thread.


Yes, I assume you should still call it for the real time thread, 
but with the first param set to false?

bool dll_thread_attach( bool attach_thread = true, bool initTls = 
true )


 Made-up problem!


Made-up problems can be very useful. I got some new ideas for 
real time GC support when thinking about this… ;-)
Dec 04 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-12-03 23:53, ponce wrote:

 I have a DLL written in D that gets called by two different threads,
 created by a non-D host program (audio plugin). I did not create those
 threads, but my understanding is that they get "attached" to the D runtime.


No, the runtime in D doesn't know anything about threads created outside 
of D, unless you explicitly register them with the runtime.

-- 
/Jacob Carlborg
Dec 04 2014