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

[john skaller]

On 03/02/2012, at 11:55 AM, Martin Lucina wrote:

> 
> One extra indirection per load, that has nowhere near the overh

It's implementation dependent of course. I have no idea how say GNU
does it on say Linux. An obvious fast way to do it is allocate a mapped
VM page for every thread. Cost: 4K (page size). Then the hardware
mapping will context switch automatically, at some cost to context
switches.

Another way to do it would be to use traps, and then use Posix
TLS: that's extremely slow (you're getting and setting values
by a string key if I recall .. gak!)

Also there's a serious overhead in all these cases added if you're
using a shared library, since the library can't know the address
of errno, you need extra indirections, just as you do for *all*
global memory.

> 
>> Fast barriers are provided on multi-cores, implemented directly in the hardware.
>> There are also lock free synchronisation primitives on all modern CPUs.
>                                           ^^^^^^^^^^
> 
> Primitives yes. You still need to implement the full lock
> free algorithms, e.g. ypipe_t. Speaking from experience, getting lock
> free algorithms right is really hard.


*If* it were possible to use it in 0MQ that would be an argument for
putting it in the core of ZMQ instead of making the user do it.
I have no idea if any of the operations could benefit from it.

The one that comes to mind would be maintaining the trie
in the PUB sockets. You might get away with that without
needing locks if you used the right kind of tree, I don't know.

--
john skaller
skaller at users.sourceforge.net