[zeromq-dev] libzmq and TLS (thread local static) ?

Laurent Alebarde l.alebarde at free.fr
Sat Feb 1 13:16:50 CET 2014


Thanks for the precision Goswin. It is ok to have objects which you 
cannot share between threads. But at least it is important that 
functions exposed in the API are usable in any thread, even if the 
objects passed as arguments are not shared between threads.

I have just had such issue while designing a stateful function that 
needs static variables. So here I had to use thread_local. I have tested 
it with 50 threads runned in parallel, that's alright. The function 
asserts if no TLS is available.
An alternative would have been the caller passes a struct as argument, 
but I find it too heavy.

I will propose a pull request this week-end. It is another version of 
zmq_proxy_chain, I called it zmq_proxy_open_chain, and it includes the 
end-points. So you can chain any proxies just in main for example. Very 
cool to deal with protocol layers as you have suggested me, or for quick 
prototyping. It really saves a lot of code.

Possibly the best is to replace simply zmq_proxy_chain instead of adding 
a new function since you can do zmq_proxy_chain with 
zmq_proxy_open_chain. There are two additional arguments, one for a 
socket array of end-points, and one for the internal polling time-out. 
It returns the index of the end-point triggered if any, or 0. The name 
is "open" because when time-out is set, there is no more internal loop 
and the application has to manage it.

Cheers,

Laurent

Le 01/02/2014 13:00, Goswin von Brederlow a écrit :
> On Wed, Jan 29, 2014 at 02:39:46PM +0100, Laurent Alebarde wrote:
>> Hi Devs,
>>
>> I assume every function in the libzmq API is thread safe, but there
>> are static variables in the code and no use of __thread ? Are all
>> static variables defined in libzmq global to all threads ?
>>
>> If I add a static variable which need to be thread local, say inside
>> zmq::proxy, is it all right to add something like this in zmq.h ?
>>
>> #if (__cplusplus > 199711L) || (defined(__STDCXX_VERSION__) &&
>> (__STDCXX_VERSION__ >= 201001L))
>> #define _TTHREAD_CPP0X_
>> #endif
>>
>> #if !defined(_TTHREAD_CPP0X_) && !defined(thread_local)
>> #if defined(__GNUC__) || defined(__INTEL_COMPILER) ||
>> defined(__SUNPRO_CC) || defined(__IBMCPP__)
>> #define thread_local __thread
>> #else
>> #define thread_local __declspec(thread)
>> #endif
>> #endif
>>
>> Found here: https://github.com/DFHack/dfhack/blob/master/depends/tthread/tinythread.h
>> About __thread and thread_local:
>> http://stackoverflow.com/questions/7047226/using-thread-in-c0x
>>
>> Usage:
>>
>> static __thread char *p;
>>
>> Cheers,
>>
>>
>> Laurent
> As a side node: zmq is not thread safe, only parts of it are. Never
> share sockets between threads for example. I would assume any thread
> related function not to be thread safe, as in you can't call them from
> two threads with the same socket. I bet message functions are also not
> made thread save.
>
> It goes with the "just don't share state" philosophy.
>
> MfG
> 	Goswin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140201/aa849e12/attachment.htm>


More information about the zeromq-dev mailing list