Sanne/JGroups — comment on commit b2c4ad53aa9f76e7018a45a4626c66c52e7ee349
File:  line 0
By Sanne:

So I've run some performance tests, and it seems performance doesn't change with this patch. BUT I just have a dual core + hyperthreading laptop, which makes it hard to understand how volatiles will impact on real world servers.

As I mentioned in the pull request, I'm not expecting you to merge this but wanted to talk about the approach, and found it easier to express myself in code.

My idea is that the Read/Write locks serve well when needing to read consistency across multiple values. but in some cases like #size() the invoker had to acquire a readlock, having to wait for a writer to finish, to read a single atomic value. Making some selected values (not all!) volatile we can reduce the contention a bit. Of course this is hairy and messy, if you're rewriting a better implementation there's no point in wasting your time discussing this. problem is that Infinispan needs something soon, so I'm considering it a backup plan.

Anyway, if we can apply this trick just to the two fields as above, then it won't buy us a significant improvement; I was more of thinking to explain you the idea with this patch and see if you can point out other cases which could benefit as well.. I can't go further without risking to change correctness, but like you pointed out on JMS there might be some race conditions which are acceptable.