Viewing profile — mjpt777

The driver does not allocate in the main message flow so GC does not factor in. Also the driver can run out of process and not be impacted by client processes.

Thanks for the feedback. I'll adjust my terminology to be more precise as it is the right thing to do. Doing things in the open is a great way to learn. I'm not shy of airing my la…

While one thread is in the action of rotation other producers return right away from the offer. The possibility of starvation occurs if the same thread each time it retried, that b…

When I re-read the definitions I can see what you take from it. I think it comes down to what you consider as systemic progress. With respect to the preciseness of the definitions …

I've read the _The Art of Multiprocessor Programming_ and am happy to read it again. Maybe I have misinterpreted. So if "killed mid-operation" must be supported then I don't see ho…

Writer two is not blocked, it is not waiting, it is not being obstructed. It is wait-free. It returns and can do whatever work it wishes. However the data structure would be corrup…

You keep saying you are not an expert but keep pushing the point :-) Try this. A process could have a rogue thread scribbling on memory and thus corrupting it. Such a process then …

If you look at the code the reader does not read the tail. It skips forward reading the length fields. It would never see the writer two message and it never blocks. It just thinks…

Please read the algorithm in code. No threads ever wait. :-)

I understand the point that we need to make software robust. No single algorithm can cope with every possible failure mode. That is why we need multiple instances run on multiple n…

Thanks for the link. If you look at the implementation no thread is ever stopped from completing. If a producing thread was killed mid operation by another malicious thread then th…

Can you point to a respected publication that states that is the definition of a wait-free algorithm, i.e. that other threads must help and it must cope with killing the thread ext…

Can you expand on how you see the writer can "fail"? Also please relate this to other algorithms you see as wait-free but don't have your failure issue. The code is very simple and…

I asked the question if this is based on conjecture or experimental evidence. I'm happy to base my view on experimental evidence from my own research and testing.

I'm sorry but this analysis is completely wrong. I don't work for Azul but have used C4 and spent time studying it. C4 does not use transactional memory, it does however employ a v…

x86 is a total store order memory model so any ASM MOV instruction that writes to a memory address will eventually be seen when the store buffer drains. In code we must ensure the …

You are absolutely right that volatile is inadequate for ordering C/C++ concurrent algorithms, and memory barriers/fences are additionally required. I tried to focus on the hardwar…

I like to have only one writer thread for any data. This can have its own flyweight. Other threads can be readers each having their own read only flyweight implementation.

In finance you may be re-evaluating a whole portfolio of assets, or doing a value at risk (VAR) calculation across everything. More often you want low-latency access to the entire …

Interesting. It sounds like your issues are IO dominant since you do not mind the JVM startup cost from Hadoop for each query on each node. I'm more often looking at large data tha…

How would it work with object pooling if I wanted to query a large table of data? This is often needed in real big data applications.

Most of those frameworks you reference are much greater than 1 microsecond round trip which is the same ballpark as good network IO. For IPC this is much less. I operate in the fin…

State of the art network hop is less than 3us so this is relevant. For on box IPC which can be as low as 100ns then very very relevant.

The byte[] buffer is deliberate because that is what will typically be passed to the network or IO device, so easier integration. If you check the code you will see the buffer is o…

A good posting showing the effect of setting thread affinity for version 1.0 of the Disruptor. http://java.dzone.com/articles/java-threads-steroids