Subj : Re: Windows Suspend/ResumeThread API equivalent for Linux or POSIX?
To   : comp.programming.threads
From : David Schwartz
Date : Wed May 11 2005 09:37 pm


"Chris Thomasson" <_no_damn_spam_cristom@_no_damn_comcast.net_spam> wrote in 
message news:IsSdnUOMFMv9LR_fRVn-og@comcast.com...

> Here is a paper describing the original SMR algorithm:
>
> http://www.research.ibm.com/people/m/michael/ieeetpds-2004.pdf

    I can tell you from experience with similar algorithms that these 
algorithms do not work well in user-space. To get the performance boost, you 
need more control over your environment and the low-level scheduling 
behavior than is possible to get in that environment. (Though they may get 
you real benefits in kernel space.)

    I can also tell your from experience that it is often the case that when 
you think you need this type of alogorithm, what you really need to do is 
rearchitect or make other subtle changes. Avoiding contention in the first 
place is better than algorithms that make contention less expensive.

    Of course, I'm not familiar with this exact algorithm or your exact 
application. So you may have the 2% case where the usual guidelines break. 
Are you *sure* portable algorithms with mutexes won't get you sufficient 
performance? (Or is this a research or proof of concept kind of thing?)

    I would also warn you against making design changes based upon 
benchmarks on unrealistic workloads. Many lock-free algorithms, for example, 
perform better than locking algorithms on unrealistic workloads. On 
realistic workloads, the descheduling of a conflicting thread allows both 
threads to run with no further conflicts. This is much more efficient than 
cache ping-ponging as both threads operate on the same data even with no 
locking cost.

    Descheduling a thread that's conflicting with another thread is *good* 
and running it later when it won't conflict with anything is *great*. 
Running both threads slowly with a lock-free algorithm is bad because work 
that must be done slowly is done instead of work that can be done quickly. 
(Of course, you don't see this on unrealistic workloads because there's 
nothing else to do.)

    Think about it. Your intuitions may be wrong.

    DS

.