@giampaolo.rodola: It definitely helps.


Conceptually, SyncManager provides "distributed shared memory" where lists, dicts, etc. are held in memory by one process but may be accessed remotely from another via a Proxy Object.  Mutating a dict from one process requires sending a message to some other process to request the change be made.

In contrast, SharedMemoryManager provides non-distributed shared memory where a special region of memory is held by the OS kernel (not a process) and made directly addressable to many processes simultaneously.  Modifying any data in this special region of memory requires zero process-to-process communication; any of the processes may modify the data directly.

In a speed contest, the SharedMemoryManager wins in every use case -- and it is not a close race.  There are other advantages and disadvantages to each, but speed is the key differentiator.


Thinking ahead to the future of SharedMemoryManager, there is the potential for a POSIX shared memory based semaphore.  The performance of this semaphore across processes should drastically outperform SyncManager's semaphore.  It might be something we will want to support in the future.  SharedMemoryManager needs a synchronization mechanism now (in support of common use cases) to coordinate across processes, which is why I initially thought SharedMemoryManager should expose the Lock, Semaphore, Event, Barrier, etc. powered by distributed shared memory.  I am no longer sure this is the right choice for three reasons:
(1) it unnecessarily complicates and confuses the separation of what is powered by fast SystemV-style shared memory and what is powered by slow distributed shared memory,
(2) it would be a very simple example in the docs to show how to add our existing Lock or Semaphore to SharedMemoryManager via register(),
(3) if we one day implement POSIX shared memory semaphores (and equivalent where POSIX is not supported), we will have the burden of an existing lock/semaphore creation methods and apis with behavioral differences.


I propose that it would be clearer but no less usable if we drop these registered object types (created via calls to register()) from SharedMemoryManager.  It is one line of code for a user to add "Lock" to SharedMemoryManager, which I think we can demonstrate well with a simple example.