I've been trying out std.concurrency, and it's MPI, and found it
very easy to use. It has been working well in most of my toy
programs so far, but I see a HUGE glaring flaw with it. I mean:
SHOWSTOPPER.
Basically, I can't help but feel the thing has an hopelessly
thread-global "mailbox" approach to the problem. This is all fine
and dandy if there is only a single "canal" of communication
between the master and the child/children.
But what happens if you have 2 objects at once that want to
communicate with their children? They have to share the global
mailbox, making things very complex.
In my program, I have simple objects: "Manager"s, that spawn a
child thread to do work. This works fine if I have a single
Manager, but how do I manage having 2 Managers at once? What
should a manager do if it calls "receive", and notices the
message wasn't meant for him?
I can write an internal service that can manage the mailbox for
all my managers, but that is a *very* closed approach. In
particular, I'm planning to distribute a module with integrated
multithreading. What if my clients also want to do MPI on their
end? How does that work?
------------
Is there any way for an object to create its own personal
MailBox? How would you tackle the problem? Does any one have any
(simple) literature on the subject?
- Using objects that manage threads via std.concurrency monarch_dodra
-
