Subj : Re: Lock Free -- where to start To : comp.programming.threads From : David Schwartz Date : Wed Sep 28 2005 01:13 pm "Joe Seigh" wrote in message news:oKadnXgTBfuiLafeRVn-qg@comcast.com... > David Schwartz wrote: >> Let me just give you my general caveat about lock free code. First, >> lock free code is generally non-portable and extremely complex. Such code >> can easily contain bugs that are extremely difficult even for experts to >> spot. The complexity is almost always unnecessary. >> Lock free algorithms work great in kernels and low level threading >> libraries for a variety of reasons. Portability is not that important. >> The probability that there are other things to do is lower in core code >> (because everything passes through it). But for application code, or even >> most libraries on top of threading libraries, it's a pure loss. > So Java isn't portable or they shouldn't have put support for lock-free in > Java or what? Java is quasi-portable. Java reflects a design decision that you'll take all the performance penalties up front, and then you can use lots of clever tricks to get the performance back. I find that an odd compromise. If you care about performance, why would you force a memory model that may or may not match the hardware at all? And if you don't care about performance, why are you trying to mess with lock free algorithms? In any event, I believe it is impossible to construct lock-free algorithms in Java, the way the term "lock free" is ordinarily used. Java does not let you get close enough to the hardware to know if there are locks or not. DS .