[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.20.13.1706181437060.21867@monopod.intra.ispras.ru>
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.
