~skeeto/public-inbox

2 2

Another question about your concurrent queue

Details
Message ID
<CAKF5_TkOS34sjbQkWkELFV5K3eO+K1pueKovm1NP1ex2_HpeBQ@mail.gmail.com>
DKIM signature
pass
Download raw message
Hi Chris,

I have a question about your concurrent lock-free queue.  You say:

> To prepare for multiple consumers, the array now has an atomic qualifier: one of the costs of       multiple consumers. Fortunately these new atomic accesses can use a “relaxed” ordering since there are no required ordering constraints. Even if it wasn’t atomic, and the load was torn, we’d detect it when attempting to commit.

Why does the job array need to be atomic? As you say, a "torn load"
would be detected by mpop_commit (I interpret "torn load" to mean
consumer 1 and 2 both mpop, consumer 1 commits, producer pushes and
starts to store data while consumer 2 is still reading). It's not
obvious to me what ordering would cause an undetectable race even if
the job array isn't atomic... Could you enlighten me? :)

Harris
Details
Message ID
<20220715003645.t3ykupplizitsfeg@nullprogram.com>
In-Reply-To
<CAKF5_TkOS34sjbQkWkELFV5K3eO+K1pueKovm1NP1ex2_HpeBQ@mail.gmail.com> (view parent)
DKIM signature
missing
Download raw message
If it's not atomic then it's a data race since there's a concurrent store 
and load on the same memory location, which simply isn't allowed. Even if 
the result is provably correct for all possible orderings, it's still 
undefined behavior. There may be unanticipated effects beyond reordering, 
though no particular examples come to mind at the moment.
Details
Message ID
<CAKF5_T=MfgenQ7kN2LzLZH3ooP7UuEMJE9aMSZXaAARJREM44Q@mail.gmail.com>
In-Reply-To
<20220715003645.t3ykupplizitsfeg@nullprogram.com> (view parent)
DKIM signature
pass
Download raw message
Got it. Thanks very much for the quick response!

On Thu, Jul 14, 2022 at 8:36 PM Christopher Wellons
<wellons@nullprogram.com> wrote:
>
> If it's not atomic then it's a data race since there's a concurrent store
> and load on the same memory location, which simply isn't allowed. Even if
> the result is provably correct for all possible orderings, it's still
> undefined behavior. There may be unanticipated effects beyond reordering,
> though no particular examples come to mind at the moment.
Reply to thread Export thread (mbox)