[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 18 Jun 2017 12:04:59 -0400
From: Rich Felker <dalias@...c.org>
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, Jun 18, 2017 at 06:05:55PM +0300, Alexander Monakov wrote:
> On Sun, 18 Jun 2017, Rich Felker wrote:
> > > I suggest dropping this and spelling 'INT_MIN + current' as 'current - 1 -
> > > INT_MAX' below. (all you need is that INT_MIN <= -INT_MAX)
> >
> > I think this can be dropped entirely for musl's purposes and
> > essentially for all practical purposes.
>
> In any case, the second half of that suggestion stands: using INT_MAX
> consistently everywhere should be better for clarity.
Yes, that seems better.
> > > > + __syscall(SYS_futex, l, FUTEX_WAIT|FUTEX_PRIVATE, current, 0) != -ENOSYS
> > > > + || __syscall(SYS_futex, l, FUTEX_WAIT, current, 0);
> > >
> > > It's probably better to put this into a new static inline function in
> > > pthread_impl.h next to __wake (e.g. __futexwait) and use it here and in __wait.
> >
> > Is there a reason __wait doesn't work?
>
> __wait doesn't fit here at all, for instance it manipulates a separate int with
> waiters count.
It accepts a null pointer for the waiters count, so that it can be
used in contexts with or without one. Any cost of the additional
conditional branches is dominated by syscall time.
Rich
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.
