I've been reading the newer C standard
(n2310.pdf to be specific).
That thing is scary.
I believe that, in the long haul, we will have to use the Atomic types stuff
that's apparently part of the C standard now.
Yeah, the switch to multi-threading made the standard way more complicated.
Sequence
On Fri, Mar 11, 2022 at 11:51:31AM +0100, Alexander Bluhm wrote:
> On Fri, Mar 11, 2022 at 05:32:11AM +, Visa Hankala wrote:
> > On Thu, Mar 10, 2022 at 07:17:43PM +0100, Alexander Bluhm wrote:
> > > On Thu, Mar 10, 2022 at 04:39:49PM +0100, Alexander Bluhm wrote:
> > > > > Below is a patch
On Fri, Mar 11, 2022 at 09:33:29AM +0100, Mark Kettenis wrote:
Hello Mark,
Unfortunately this transformation almost certainly isn't safe: for
example, the non-atomic load can return values that were never written
by any thread (e.g. due to load/store tearing amongst other fun
On Fri, Mar 11, 2022 at 05:32:11AM +, Visa Hankala wrote:
> On Thu, Mar 10, 2022 at 07:17:43PM +0100, Alexander Bluhm wrote:
> > On Thu, Mar 10, 2022 at 04:39:49PM +0100, Alexander Bluhm wrote:
> > > > Below is a patch that shows how to accomplish release semantics with
> > > > the file and
> Date: Thu, 10 Mar 2022 23:09:59 +
> From: Laurence Tratt
>
> On Fri, Mar 11, 2022 at 09:00:57AM +1000, David Gwynne wrote:
>
> Hello David,
>
> >> Unfortunately this transformation almost certainly isn't safe: for
> >> example, the non-atomic load can return values that were never
On Thu, Mar 10, 2022 at 07:17:43PM +0100, Alexander Bluhm wrote:
> On Thu, Mar 10, 2022 at 04:39:49PM +0100, Alexander Bluhm wrote:
> > > Below is a patch that shows how to accomplish release semantics with
> > > the file and refcnt APIs. (The added memory barriers ensure that the
> > > CPU
On Thu, Mar 10, 2022 at 10:45:47AM +, Laurence Tratt wrote:
> On Thu, Mar 10, 2022 at 09:05:54AM +, Visa Hankala wrote:
>
> Hello Visa,
>
> > In general, atomic_* functions have not provided implicit memory
> > barriers on OpenBSD.
>
> I've used atomics fairly extensively in other
On Fri, Mar 11, 2022 at 09:00:57AM +1000, David Gwynne wrote:
Hello David,
>> Unfortunately this transformation almost certainly isn't safe: for
>> example, the non-atomic load can return values that were never written by
>> any thread (e.g. due to load/store tearing amongst other fun effects).
On Thu, Mar 10, 2022 at 10:26:21PM +, Laurence Tratt wrote:
> On Thu, Mar 10, 2022 at 09:52:27PM +0100, Mark Kettenis wrote:
>
> Hello Mark,
>
> > If you think about it, the invariants being tested by those KASSERTs should
> > not depend on whether the old or the new value is read if another
On Thu, Mar 10, 2022 at 09:52:27PM +0100, Mark Kettenis wrote:
Hello Mark,
> If you think about it, the invariants being tested by those KASSERTs should
> not depend on whether the old or the new value is read if another CPU is
> modifying that variable at the same time. Unless of course there
> Date: Thu, 10 Mar 2022 21:43:02 +0100
> From: Alexander Bluhm
>
> On Thu, Mar 10, 2022 at 07:47:16PM +0100, Mark Kettenis wrote:
> > > In general, atomic_* functions have not provided implicit memory
> > > barriers on OpenBSD.
> > >
> > > I am not sure if the data dependency barrier is needed
On Thu, Mar 10, 2022 at 07:47:16PM +0100, Mark Kettenis wrote:
> > In general, atomic_* functions have not provided implicit memory
> > barriers on OpenBSD.
> >
> > I am not sure if the data dependency barrier is needed where
> > atomic_load_int() and atomic_load_long() are used. The memory
> Date: Thu, 10 Mar 2022 09:05:54 +
> From: Visa Hankala
>
> On Wed, Mar 09, 2022 at 08:45:35PM +0100, Alexander Bluhm wrote:
> > On Tue, Mar 08, 2022 at 04:55:56PM +0100, Alexander Bluhm wrote:
> > > Once we had the discussion where we need the READ_ONCE() macro. As
> > > modern C compiler
On Thu, Mar 10, 2022 at 04:39:49PM +0100, Alexander Bluhm wrote:
> > Below is a patch that shows how to accomplish release semantics with
> > the file and refcnt APIs. (The added memory barriers ensure that the
> > CPU completes its loads and stores to the object before dropping the
> > reference.
On Thu, Mar 10, 2022 at 02:03:26PM +, Visa Hankala wrote:
> My understanding is that OpenBSD's atomic_* instructions are relaxed
> in terms of memory order. To accomplish a specific form of semantics,
> the user adds the appropriate memory barrier instruction. Well, this
> is the plan at
On Thu, Mar 10, 2022 at 09:05:54AM +, Visa Hankala wrote:
> > As a bonus alpha gets the membar it needs.
>
> In general, atomic_* functions have not provided implicit memory
> barriers on OpenBSD.
>
> I am not sure if the data dependency barrier is needed where
> atomic_load_int() and
On Thu, Mar 10, 2022 at 10:45:47AM +, Laurence Tratt wrote:
> On Thu, Mar 10, 2022 at 09:05:54AM +, Visa Hankala wrote:
>
> Hello Visa,
>
> > In general, atomic_* functions have not provided implicit memory
> > barriers on OpenBSD.
>
> I've used atomics fairly extensively in other
On Thu, Mar 10, 2022 at 09:05:54AM +, Visa Hankala wrote:
Hello Visa,
> In general, atomic_* functions have not provided implicit memory
> barriers on OpenBSD.
I've used atomics fairly extensively in other settings. Forgive me if I'm
explaining the obvious, but I had a devil of a job making
On Wed, Mar 09, 2022 at 08:45:35PM +0100, Alexander Bluhm wrote:
> On Tue, Mar 08, 2022 at 04:55:56PM +0100, Alexander Bluhm wrote:
> > Once we had the discussion where we need the READ_ONCE() macro. As
> > modern C compiler has much freedom how to access memory, I came to
> > the conclusion that
On Tue, Mar 08, 2022 at 04:55:56PM +0100, Alexander Bluhm wrote:
> Once we had the discussion where we need the READ_ONCE() macro. As
> modern C compiler has much freedom how to access memory, I came to
> the conclusion that it would be wise to use READ_ONCE() and
> WRITE_ONCE() everywhere when
20 matches
Mail list logo
