Amit Bhatnagar wrote in message <935ksi$ai8$1@News.Dal.Ca>…
Mario Charest <mcharest@void_zinformatic.com> wrote:
:> well…after much reading… my next question is “What is wrong
:> with doing it as a resource manager?”
: Absolutely nothing.
: What is in question is that each of your resource manager
: send message to each other. But that doesn’t reduce the
: risk of potential deadlock.
Ohh i see, so I am tackling the problem ina good way (ala
resmource manager), however the potential deadlock is because
one app may not be able to reply to the sending app (thus making
the sender reply blocked). Is that right? How else is there
If you don’t have enough threads to handle the maximum number of
requests that could be sent to you at one time.
With 2 nodes it is 2 threads.
N1t1 sends to N2 (and t1 or t2 can handle it) while
N2tx sends to N1 (and the other thread is available)
(note this doesn’t account for the processes that really need the RM!)
With ‘N’ nodes it gets tricky unless you run with N+1 threads because there
is always a chance that you could get 2 process attempting to send to
each other and no threads are available to handle the request. If you
mutexs/condvars you could get into a hopeless deadlock that would be
really hard to debug.
In Nto it is possible (QNX4 was a definitive not possible unless you had a
method of synchronization between processes) but I think you need to
look carefully at what you are trying to do. This design has a process
that is both a “server” and a “peer” - one way would be to have a single
thread in each RM that is responsible for talking to all the other peers
so some amount of segmentation exists (a thread that does MsgReceive
will never issue a MsgSend (or call a function that does) to a process
it could receive from)
Just my 2 cents - the simpler the design, the easier to implement, the
more robust down the road, and you can hand it off to somebody else.
(Mario and David - Yes I forgot about threads and dispatch handling
in Nto, but I also believe there are right and wrong places to use
threads and a lot of threads are used because someone couldn’t find
a “correct” way to do something; the thread was a work-around as
opposed to a “design” issue.)