Benad's Web Site

Shared Objects

In “UNIX System V”, and OSes similar to it, there are basically two forms of inter-process communication: shared memory and message queues. In the case of OSGi inter-module communications, its service references kind of makes using shared objects the obvious choice.

While UNIX-like systems and their enforced memory protection force you to have to explicitly request shared memory regions, in OSGi all the modules run under the same object memory space, so all objects can be potentially shared. This means that for OSGi modules you can use a service reference that contains shared values that can be accessed directly or through accessor functions as a mean of implementing inter-module communications.

Now, the issue is that in typical cases different modules run in different threads, so sharing objects between them requires careful use of locking mechanisms. And this is the problem with this “shared memory” approach: it simple cases naïve locking works fine, in more complex cases you get deadlocks and obscure race conditions.

Using an embedded relational database like JavaDB or H2 to simplify the locking semantics while keeping high parallelism seems like a good idea, but those embedded databases ultimately use a single lock for the entire process as the database write lock, making parallelism limited for inter-module communications.