NLJUG- Spring Event

Twice a year the NL-JUG puts together a one day conference. Little did I know that when I submitted my abstract that I'd be delivering the after lunch keynote. So I've been having a bit of fun re-arranging slides to make them more keynote like. I've had review help from a couple of friends, some technical and some with a uncanny ability to nit in a very helpful way.

The morning I had a conversation with Heinz about some code that I decided to leave out. I had written a CAS simulation and quite deliberately not synchronized or used volatile. He quite correctly pointed out that the code should easily hit a condition where it would spin forever and it should. However I've not been able to get it to spin on my multi-core MacBook Pro nor on my hyper-threaded XP desktop. The question at hand is; can I lock down a critical section of code without grabbing a lock. To do this I use a thread to claim the block and then wait and see if the claim sticks. Its analogous to a "squatters rights" approach. So the local variable should be corrupted in a multi-core scenario. Point of interest, it isn't.

My guess is that the L1/L2 cache is being shared in the multi-core chip and that is why I can get away with not using volatile. My guess is I'd not be able to enjoy the same results running in a true SMP environment. I've not checked this thoroughly so I'll take comments from someone who really knows. Point is, the code is horrible, it contains a bug in the sense that it works only with respect to specific hardware architectures but it does work on the hardware that I'm using. I should really post the code but it really is quite ugly.

If you happen to be at the NL-JUG event please introduce yourself but be fore warned, I maybe a wee bit distracted until an hour or so after lunch. One other point, the only thing correct about the abstract on the site is that I'll be talking about concurrency.

tags: nljug  volatile  java  performance