Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 18 Jun 2017 14:49:54 +0300 (MSK)
From: Alexander Monakov <>
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.


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.