[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.20.13.1706181759000.21867@monopod.intra.ispras.ru>
Date: Sun, 18 Jun 2017 18:05:55 +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, 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.
> > > + __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.
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.
