> >
> > So, I believe that kernel support is indeed needed.
>
> Don't do in the kernel what can adequately be performed in user space.
> Let me add my own data here... I modified Matt's program to get better
> timings, and compared mutexes to a spinlock implementation for ix86:
>
[...]
> For such short lock durations system calls are not effective. During
> the time one thread spends in sched_yield(), perhaps several
> microseconds, another thread may grab the spinlock hundreds of times
> succesfully. The effect is to inflate overall throughput but severely
> increase latency and diminish concurrency.
>
> On the other hand, for a uniprocessor spinlocks are not effective.
>
[...lots of benchmark results delete, please refer to Jeff's mail]
> My main point is that it is not adequate to measure simple lock
> throughput (iters/msec) to judge the quality of a lock algorithm, nor is
> one algorithm best suited for all situations. The spinlock code is
> convenient because it is easy to tune for different machines, especially
> SMP kernels. The lock-test porgram is not very realistic since most CPU
> time is spent competing for a lock, but it serves as a reasonable
> benchmark for lock contention.
>
Jeff,
I'm not sure I understand what you're trying to say here.
Your measurements demonstrate that spinlocks are faster than anything
else if there's at least as many processors as there are threads.
I fully agree and expect this.
But I don't see what I should conclude? That I should use spinlocks
implemented via atomic exchange operations in cases like the one we
discussed, where you have one heavily contended lock in your application?
If that were your conclusion, I would have to disagree, simply because
we cannot assume that there's at least as many processors as there
are threads.
We're not looking for a decision as to whether to use spinlocks or not,
we're looking for a way to improve the implementation of pthread_mutex_lock
in the contended case. We cannot even assume that the lock is only held
for short-durations, which is another prerequisite to using spinlocks
to my knowledge.
But maybe really don't understand what you are suggesting.
Could you explain?
- Godmar
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
