Subj : Re: Lock Free -- where to start
To   : comp.programming.threads
From : David Schwartz
Date : Wed Sep 28 2005 04:34 pm


"Chris Thomasson" <_no_spam_cristom@no_spam_comcast._net> wrote in message 
news:_42dnY09Tc9KiKbeRVn-jw@comcast.com...

> The ability for read-only iterations (frequent database searches?) to 
> achieve a substantial increase in the number of reads per-second, 
> per-reader-thread, would most certainly be a loss...

    I can't figure out what scenario you're talking about. If you have a 
large chunk of read-mostly data, how can the overhead of bouncing around one 
cache line prior to these large accesses possibly  matter? If you're talking 
about lots of small accesses, well, then your lock scope is badly chosen.

    However, I do agree that you picked one of the best examples. Dealing 
with large collections of read-mostly data is probably one of the best cases 
for a lock free algorithm.

    As for hiding non-portable code behind a portable API, that argument 
misses the point. If you use an API to do something, you do not care whether 
there's a lock free or lock based algorithm behind the API. The issue is 
about *writing* code, not using code.

    DS

.