[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150517061430.GL17573@brightrain.aerifal.cx>
Date: Sun, 17 May 2015 02:14:30 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Deduplicating atomics written in terms of CAS
On Sun, May 17, 2015 at 09:00:15AM +0300, Alexander Monakov wrote:
> It seems the prototype of a_cas_p has changed:
>
> void *a_cas_p(volatile void **p, void *t, void *s)
>
> Shouldn't the type of the first argument be 'void * volatile *'?
Yes, thanks for catching it. BTW changing from the current void* to
this will probably expose minor aliasing bugs I want to fix. I might
just change all pointers used with a_cas_p to uintptr_t, and have
a_cas_p work on uintptr_t, and force the code using them to cast back
and forth to real pointers. Alternatively we could try to get rid of
a_cas_p entirely. I'd like to trim down both the set of atomic
primitives we're using and the number of direct uses of atomics
(versus higher-level primitives like locks). Some candidates to
remove:
- a_cas_p
- a_or_l (only used in sigaction; could be replaced by a_or)
- a_and (not used at all)
- a_and_64/a_or_64 (malloc only; these are misnamed too)
Actually a_cas_p is the hardest to remove; while none of the users of
it are performance-critical themselves, they are using it as a means
of avoiding locking where the consumer of the data being written can't
or doesn't want to require a lock.
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.
