[zeromq-dev] preparing bindings for 2.1 release?

[Alexey Ermakov]

On Fri, Oct 1, 2010 at 6:42 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:
>> I think that you still need to ensure a memory barrier for a socket
>> migrating between threads. Not sure what's the cheapest way to do that
>> in JNI. Maybe it would be easier to declare send()/recv()/*sockopt
>> synchronized?
>
> That's what the language runtime should do anyway when it passes object
> between OS threads -- otherwise the new thread could see inconsistent data
> in the memory. We can just piggyback on the runtime's memory barrier.

Java has a rather complicated memory model and doesn't guarantee a
memory barrier unless the programmer requests one by using
synchronization, volatile variables or java.util.concurrent
primitives. This shouldn't be a problem, though, because according to
the comments in
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6192910>, JNI
invocations always include a memory fence, so no modifications would
be needed. I'll have a look at the JNI spec in case that has changed,
though.

Somewhat related: is there a guide to thread safety guarantees of 2.1
sockets? For example, is it safe to close() the socket from one thread
if another thread is blocked on recv()/send()? What about poll()? Can
multiple threads call send() in parallel or they need to be
synchronized manually?
These things should probably be documented in the javadocs.