Subj : Re: Lock Free -- where to start
To   : comp.programming.threads
From : Chris Thomasson
Date : Fri Sep 30 2005 12:03 am

>> 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.

Reader threads getting a vast increase in the number of reads to a shared 
database-like structure they can perform per-second. IHMO, this can be very 
important.




> 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?

Lock-free, or not; atomic operations and membars reduce shared reads 
per-second, in virtually all cases:

http://www.rdrop.com/users/paulmck/RCU/lockperf.2004.01.17a.pdf


In some cases, it can be a difference between tens-of-thousands of reads 
per-second, or million+ reads-per-second...

No kidding.




> If you're talking about lots of small accesses, well, then your lock scope 
> is badly chosen.

Probably.




>    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.

Very true.




>    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.

I have a feeling that users are going to start to care about how good an API 
can "scale-up" to the new systems that are going to come out. Though I do 
agree that the user won't really care about what a vender uses, lock-free or 
lock-based, to achieve that.


> The issue is about *writing* code, not using code.

Ahh. Yes, actually writing lock-free code can be very tedious, indeed:

http://groups.google.com/group/comp.programming.threads/msg/423df394a0370fa6


;)

.