On 10/06/15 16:18, Jan Wieck wrote:
>
> I have played with test code that isolates a stripped down version of s_lock()
> and uses it with multiple threads. I then implemented multiple different
> versions of that s_lock(). The results with 200 concurrent threads are that
> using a __sync_val_compare_and_swap() to acquire the lock and then falling back
> to a futex() is limited to about 500,000 locks/second. Spinning for 10 times and
> then doing a usleep(1000) (one millisecond) gives me 25 million locks/second.
>
> Note that the __sync_val_compare_and_swap() GCC built in seems identical in
> performance with the assembler xchgb operation used by PostgreSQL today on x84_64.
These numbers don't work for me. Do IUC that you are not holding the lock for
any reasonable time? If yes, the test case is invalid (the uncontended case is
never relevant). If No, the numbers don't match up - if you held one lock for
1ms, you'd not get more than 1000 locks/s anyway. If you had 200 locks, you'd
get 200.000 locks/s.
Can you please explain what the message is you are trying to get across?
Thanks, Nils
