Java Performance Services
Training, Seminars, Benchmarking, Tuning

Java Performance Tuning Course


Chania Crete, May 17-20, 2010


Sun Extreme Learning EXL-2025

Houston, December 1-4,2009
New York, December 8-11, 2009
Washington DC, January 5-8, 2010



San Francisco, January 11-14

Anti-if

I have joined Anti-IF Campaign

Calendar

««Nov 2009»»
SMTWTFS
1234
5
67
891011121314
15161718192021
22232425262728
2930

Performance Anti-Patterns

My Top Tags

                                       

Mailing List

My RSS Feeds








NLJUG- Spring Event

posted Friday, 8 June 2007

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: