[zeromq-dev] Whcih API calls are thread safe ?

john skaller skaller at users.sourceforge.net
Sun Jan 22 17:02:56 CET 2012


On 23/01/2012, at 2:35 AM, Pieter Hintjens wrote:

> On Sun, Jan 22, 2012 at 8:57 AM, john skaller
> <skaller at users.sourceforge.net> wrote:
> 
>>> I assume, that ALL socket oriented calls MUST be called from the thread,
>>> which created the socket.
>> 
>> That's not my understanding: the API notes say that a socket isn't thread safe,
>> and a memory barrier must be used. Which implies it can be used on any thread
>> provided you organise locking or whatever.
> 
> We removed all discussion of socket migration from the Guide after
> finding that people would, over and over, read the first part, not
> understand the memory barrier part, and then complain when their code
> started crashing. So the Guide says, "don't do it, period". The man
> page says "don't do it, but if you must, use a fmb".


lol :) 

However it is important to know the actual rules. At present, the Felix binding
is just a simple wrapper around ZMQ. But it will not stay that way
because blocking operations block the containing pthread and thus
all the fibres. Instead, I/O ops will be delegated to a separate thread,
which allows the calling fibre to block, but not other fibres in the same
pthread.

This means that some socket ops will be done in the application pthread,
though I'm not actually sure which ones yet .. :)

But others .. including data transfers .. will be done in another thread.
The delegation mechanism uses a thread safe queue (i.e. the push
and pop operations use locking to ensure the queue integrity).

So this should be enough, provided two fibres don't access the same
socket (because a second fibre might do so concurrently with the
actual I/O op and without a barrier). The delegating fibre CANNOT
do anything with the socket because it has been put to sleep.

OTOH, for operations which are NOT delegated, two fibres can
access the socket as they please since they exchange control
by their own volition (actually .. by reading and writing on
channels .. which are somewhat similar to 0MQ sockets
except they're strictly unbuffered)

YMMV .. but in my plan, moving sockets across thread boundaries
is mandatory .. in fact the whole async/IO paradigm is based on it.

--
john skaller
skaller at users.sourceforge.net







More information about the zeromq-dev mailing list