Subj : Re: Lock Free -- where to start
To   : comp.programming.threads
From : Chris Thomasson
Date : Thu Sep 29 2005 11:06 pm

> Ok, but in this case someone asked for resources on lock-free program-
> ming.
>
>>  - one of the usual suspects suggests "using lock-free techniques".
>
> Yes, and it's pretty anoying when Chris Thomasson jumps into the
> scene iust to emphasize his work

Well, the OP did ask for some open-source.


> (with a IMHO very ugly coding-style).

Sorry about that.

;)




> He suggessts to use lock-free-processing although the cases where this
> is really necessary because of a notable performance-advantages are
> rarer than the neelde in a haystack.

The libraries basic philosophy is to blend "lock-free with lock-based 
programming". I also post a clear link to a discussion of some of the most 
important "caveats" that come along with lock-free programming. I clearly 
suggest that programmers "test" AppCore against "traditional lock-based" 
solutions, that's all. Why not let application programmers try to 
"experimentally improve" some of their existing designs? When the multi-core 
stuff becomes available to "regular customers", it may require some 
applications to "scale-up". In the next couple of years, you "might be" 
receiving questions from customers like:


I bought one of those new dual-core systems with 4 processors, and your 
application suite seems to execute critical tasks a little bit slower than 
usual! Why is that? Do I have to set some special configuration options? 
Please help...




> And in the current case, he sug-
> gests his nearly undocumented and hardly readable source as an origin
> for lock-free-processing knowledge.

It's only an example. I didn't really have time to document it, because I 
was working hard on something else. AppCore is pretty much dead right now. 
Anyway, I don't claim that AppCore is an "origin for lock-free-processing 
knowledge"; after all, its experimental. If I am coming across that way, I'm 
sorry.

.