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 -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
