Re: Using a lot of Maps
markspace wrote:
On the message passing system I worked on, you needed a sender and a
receiver. You won't want to broadcast to all processes, just the ones
that want to listen. If you have 50 threads that need to synchronize,
you don't want to dump the cache of the other 950 in the system. This is
the advantage of message systems, as I understand it. They have an
explicit target, so you can target only 50 instead of the entire 1000.
Message passing systems are typically implemented in the kernel, with
support from hardware, but not fully hardware themselves. In this case,
the kernel would probably need to look up the PID of the processes, get
which CPU they're running (if any, could be blocked and swapped out),
and send the message to those HW caches.
This could be received asynchronously by the CPUs, with out an explicit
receive on the target process, I'll give that. And HW can assist in the
look-up, that's been done. But there's still a context switch to deal
with (these HW access are usually privileged and not available to user
processes). And the context switch is the overhead, as I understand it.
Fine grained context switching is going to cause slowdowns.
Are you discussing message passing on top of shared memory or shared memory on
top of message passing? I got a little dizzy, but there are ways to do either
that play to the strengths of the underlying platform. (There's also
something to be said for the hybrid approach.)
You can use shared memory to deliver messages using locking and releasing
threads to send and receive to/from the shared area. This allows quite fast
delivery of messages. In a message-passing system you might actually have
such a thing happening to support processor-local messages.
Conversely, in message-passing systems a shared resource typically hides
behind a "resource manager" that operates receive-mode to dole out resource
services on demand. You could put shared data behind a resource manager,
which then will deliver (or simulate) synchronization services.
Upthread, markspace alluded to alternative scenarios where message passing or
shared memory might be the natural paradigm. Different layers, diverse
modules, might call for different patterns.
--
Lew