digitalmars.D - Is this the best way to share Tids between threads?
- Charles Hixson via Digitalmars-d (22/22) Aug 13 2016 I'm trying to figure out the best way to have multiple threads that can
- angel (4/4) Aug 14 2016 Let each thread have a name related to its task.
- Charles Hixson via Digitalmars-d (21/25) Aug 14 2016 Sorry this ended up here rather than at learn. I followed up there with...
- TencoDK (4/28) Aug 14 2016 I'm sending immutable Tid[string] to each thread, though I don't
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
Let each thread have a name related to its task. It is like having a shared Tid array, but already implemented. Reference:
Aug 14 2016
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:
Aug 14 2016
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