[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ✘64-bit time_t on glibc 2.34 and up

From: Gary E. Miller
Subject: Re: ✘64-bit time_t on glibc 2.34 and up
Date: Fri, 13 Jan 2023 13:50:00 -0800

Yo James!

On Fri, 13 Jan 2023 13:43:38 -0800 (PST)
James Browning <> wrote:

> > On 01/13/2023 1:06 PM PST Hal Murray <> wrote:
> > 
> > 
> > If we make any changes to SHM, we should switch to a setup where
> > the memory is read only. The idea is to allow multiple readers.
> > 
> > The trick to implementing that is to have 2 counters.
> > X and Y are initialized to the same value.
> > The writer bumps X, updates the data, then bumps Y.
> > The reader grabs Y, grabs the data, then grabs X.
> > If X and Y are the same the data is valid. If not, try again.  
> I've heard you mention this before, and I specced it
> by calling them bookends instead and sticking them at
> opposite ends of a 4KiB page-sized struct.

How do you force 4kB page size?  Or 4kB alignment?  Maybe the
kernel is using hug pages?

On a modern CPU, you have no way to force what gets written first.
You used to me able to depend on the write order of memcpy(), but not
true for a while.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgp_4O4JYMWUr.pgp
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]