[zeromq-dev] C++ assertion failed with Java client

[john skaller]

On 02/02/2012, at 10:36 PM, Martin Lucina wrote:

>> Q: is it technically feasible to make a thread-safe wrapper around 0MQ sockets?
> 
> Sure, chuck a bunch of locks around socket-related calls? A mutex implies a
> full memory barrier, so things should work OK at least on cache-coherent
> architectures.
> 
> Performance will take a nose-dive of course, but if that is not a concern,
> go for it ...
> 

I would put these directly in the official ZMQ C API.

The rationale is that ZMQ's own rationale is that you can program with ZMQ
instead of using all those nasty locks, share memory barriers, and all the
other things that make multi-threaded programming a nightmare.

In Felix I have a garbage collector: flx_collector_t and a second collector
flx_ts_collector_t which is a thread-safe wrapper around the first one: both are
derived from flx_gc_t abstract class in the C++ code. 

The wrapping should be done in C++ and exported to C, not in C around
the C API. IMHO. Which means it has to be part of the ZMQ C API standard.

The reason is I think

(a) the locking can be made somewhat "conditional" and
 
(b) because of the particular structure of ZMQ other techniques
which can avoid mutex or semaphores may be used.

(c) it makes the Windows and Posix usage of ZMQ the same
in an environment where 0MQ sockets are used in several threads,
rather than forcing the client to use OS local locking techniques.


It's not clear if the "right way" is to have a zmq_context, and a 
zmq_ts_context, so that if you make the latter all the socket
objects spawned off it are thread safe. This is clearly simpler
and avoids changes to the other functions, but it provides
less control and therefore imposes an overhead.


--
john skaller
skaller at users.sourceforge.net