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
