Date: Fri, 23 Dec 2011 08:34:08 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-fs@freebsd.org Cc: Ed Schouten <ed@80386.nl>, pjd@freebsd.org Subject: Re: Changing refcount(9) to use a refcount_t Message-ID: <201112230834.08198.jhb@freebsd.org> In-Reply-To: <20111222214728.GV1771@hoeg.nl> References: <20111222214728.GV1771@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, December 22, 2011 4:47:28 pm Ed Schouten wrote:
> Hi all,
>
> As some of you may know, the upcoming C standard has support for atomic
> operations. Looking at how they implemented it, it seems that they tried
> to keep it somehow compatible with existing compiler standards. For
> example, one could implement a poor-man's version of it as follows:
>
> | #define _Atomic(T) struct { pthread_mutex_t m; T v; }
> |
> | #define ATOMIC_VAR_INIT(value) { PTHREAD_MUTEX_INITIALIZER, (value) }
> |
> | #define atomic_store(object, value) do {
> | pthread_mutex_lock(&(object)->m);
> | (object)->v = (value);
> | pthread_mutex_unlock(&(object)->m);
> | } while(0)
> |
> | ...
>
> Voila; atomics!
>
> Just out of curiosity, I did some experiments with this, where I have a
> <stdatomic.h> that works with both Clang and GCC (except ARM and MIPS,
> for some reason). My first test subject: <sys/refcount.h>.
Hmm, are we really aiming to replace <machine/atomic.h> with the C1X API
instead?
FWIW, I thought about making a refcount_t when first writing <sys/refcount.h>
but bde@ talked me out of it. Bruce is of the general opinion that we should
avoid adding new *_t typedefs when we can help it.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201112230834.08198.jhb>