Date: Sun, 18 Jun 2017 14:49:54 +0300 (MSK) From: Alexander Monakov <amonakov@...ras.ru> To: musl@...ts.openwall.com Subject: Re: [PATCH] a new lock algorithm with lock value and CS counts in the same atomic int On Sun, 18 Jun 2017, Jens Gustedt wrote: > > This looks wrong in single-threaded case, __lock doesn't touch the > > lock, but __unlock modifies it unconditionally. > > Right, probably there should be the same test as for the lock case. Checking libc.threads_minus_1 on the unlock path won't work: as threads exit, it may become zero even though it weren't when acquiring the lock. > Or we should drop that test all along. I don't think that it still serves > much purpose here. This is just trading one memory access against another. It trades a simple read access against an atomic modification, though. I think the fastpath in __unlock can check the value of the lock against 0, exiting immediately if equal. Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.