www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is this the best way to share Tids between threads?

reply Charles Hixson via Digitalmars-d <digitalmars-d puremagic.com> writes:
I'm trying to figure out the best way to have multiple threads that can 
each send messages to the other threads.

I've come up with two basic approaches, one uses the main thread as a 
relay, and the other uses a shared array of Tid...thus:

import    std.concurrency;
import    std.stdio;

import    core.thread;

shared    Tid[8]    tidList;

void    worker (int ndx)
{ Thread.sleep (5.msecs);
     writeln ("worker is done");
}

void    main()
{
     auto tid    =    spawn (&worker, 0);
     tidList[0]    =    cast(shared Tid)tid;
     Thread.sleep (40.msecs);
     writeln ("main is done");
}

Is there a reasonable way to decide which way is best?  Is there a 
better way that I just haven't thought of? Are there problems with 
sending messages via shared Tids that I just haven't thought of yet?
Aug 13 2016
next sibling parent reply angel <andrey.gelman gmail.com> writes:
Let each thread have a name related to its task.
It is like having a shared Tid array, but already implemented.
Reference:
http://dlang.org/phobos/std_concurrency.html#.register
Aug 14 2016
parent Charles Hixson via Digitalmars-d <digitalmars-d puremagic.com> writes:
Sorry this ended up here rather than at learn.  I followed up there with 
something more explicit. See "Multi-Thread message passing approach" in 
learn.

The problem here is that the threads will be doing the same thing, sort 
of, modulus an integer.  And the number of them should be set at run 
time by checking the number of available CPUs. Which is handled in 
today's code example (see learn), but I'm not really sure I'm doing 
things the best way, or even that it's safe.  (I'm using a shared Tid[].)

There will be a couple of specialized threads, for which that looks like 
a good approach, though I could easily just special case those.  It's 
the more general case that I'm concerned about.

If the approach of using "shared Tid[]" is safe, then it's probably the 
best approach, but since I have to cast away the "shared" to use it, I 
worry about it's safety.  If it's unsafe, then I probably need to set up 
an relay in the main thread.  I suppose I could register "th1", "th2", 
... "thn" and then only spawn a limited number of threads, and then use 
that to get the Tid[] as a local variable, or some other work around, 
but that seems quite clumsy, besides, if "shared Tid[]" is unsafe, then 
probably so is using Tids retrieved by locate in multiple independent 
threads.


On 08/14/2016 01:55 AM, angel via Digitalmars-d wrote:
 Let each thread have a name related to its task.
 It is like having a shared Tid array, but already implemented.
 Reference:
 http://dlang.org/phobos/std_concurrency.html#.register
Aug 14 2016
prev sibling parent TencoDK <marisalovesusall gmail.com> writes:
On Sunday, 14 August 2016 at 00:33:18 UTC, Charles Hixson wrote:
 I'm trying to figure out the best way to have multiple threads 
 that can each send messages to the other threads.

 I've come up with two basic approaches, one uses the main 
 thread as a relay, and the other uses a shared array of 
 Tid...thus:

 import    std.concurrency;
 import    std.stdio;

 import    core.thread;

 shared    Tid[8]    tidList;

 void    worker (int ndx)
 { Thread.sleep (5.msecs);
     writeln ("worker is done");
 }

 void    main()
 {
     auto tid    =    spawn (&worker, 0);
     tidList[0]    =    cast(shared Tid)tid;
     Thread.sleep (40.msecs);
     writeln ("main is done");
 }

 Is there a reasonable way to decide which way is best?  Is 
 there a better way that I just haven't thought of? Are there 
 problems with sending messages via shared Tids that I just 
 haven't thought of yet?
I'm sending immutable Tid[string] to each thread, though I don't spawn new threads after app initializing. Works well if you don't have to encapsulate your threads.
Aug 14 2016