[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ✘64-bit time_t on glibc 2.34 and up
From: |
James Browning |
Subject: |
Re: ✘64-bit time_t on glibc 2.34 and up |
Date: |
Fri, 13 Jan 2023 13:43:38 -0800 (PST) |
> On 01/13/2023 1:06 PM PST Hal Murray <halmurray@sonic.net> 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.
- Re: ✘64-bit time_t on glibc 2.34 and up, (continued)
My ignorance was Re: ✘64-bit time_t on glibc 2.34 and up, James Browning, 2023/01/13
Re: ✘64-bit time_t on glibc 2.34 and up, Richard Laager, 2023/01/13
Message not available
Re: ✘64-bit time_t on glibc 2.34 and up, Hal Murray, 2023/01/13
- Re: ✘64-bit time_t on glibc 2.34 and up, Gary E. Miller, 2023/01/13
- Re: ✘64-bit time_t on glibc 2.34 and up, Gary E. Miller, 2023/01/13
- Re: ✘64-bit time_t on glibc 2.34 and up, Greg Troxel, 2023/01/13
- Re: ✘64-bit time_t on glibc 2.34 and up, Gary E. Miller, 2023/01/13
- Re: ✘64-bit time_t on glibc 2.34 and up, Greg Troxel, 2023/01/14
- Re: ✘64-bit time_t on glibc 2.34 and up, Gary E. Miller, 2023/01/14
Message not availableRe: ✘64-bit time_t on glibc 2.34 and up, Gary E. Miller, 2023/01/13