Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming.threads > #1042

Re: Who needs acquire semantics for read operations?

Newsgroups comp.programming.threads
Date 2012-09-02 00:10 -0700
References <f5a18d06-5413-4bef-93f9-96686cd08bb9@k20g2000vbk.googlegroups.com> <504244da$0$6576$9b4e6d93@newsspool3.arcor-online.net>
Message-ID <c03062ea-577a-4113-ad9e-043c473b4221@q20g2000vbx.googlegroups.com> (permalink)
Subject Re: Who needs acquire semantics for read operations?
From Rani Sharoni <ranisharoni75@gmail.com>

Show all headers | View raw


On Sep 1, 8:24 pm, Marcel Müller <news.5.ma...@spamgourmet.org> wrote:
> On 01.09.12 10.28, Rani Sharoni wrote:
>
> > AFAIU, acquire semantics for read operations is guaranteed for
> > volatile variables by the MSVC compiler.
>
> AFAIK x86/x64 has no memory reordering anyway.
There is store-load reordering (AKA store buffer forwarding memory
model).

> VC can only compile for
> x86/x64. So volatile is mostly useless. Is mainly disables the optimizer.

Disabling the optimizer is sometime essential for correctness:
LONG InterlockedAddNonNegative(__inout LONG volatile* plValue,  __in
LONG const  lAdd)
{
    LONG lValue = 0;

    for (;;)  {
        lValue = *plValue; // volatile plValue suppress compile
optimizations in which lValue is optimized out hence MT correctness is
broken
        if (lValue < 0 || lValue ==
InterlockedCompareExchange(plValue, lValue + lAdd, lValue)) break;
    }

    return lValue;
}

BTW - do you know about any CPU architecture might perform such
temporary variable elimination hence break the above code?
(InterlockedCompareExchange is also full membar).

> > Can you think about any situation in which such guarantee on non-read-
> > modify operation is useful?
>
> Yes.
>
> A common patter is to have a state variable with a forward only state
> graph. Reading a state that is a final value in this graph is known to
> be thread-safe with acquire semantics only. Example: an object might be
> loaded asynchronously. The finished flag is final. If you check for
> finished with acquire semantics you do not need any locking unless you
> get the value "not finished". You can combine this with a conditional
> variable and the double check idiom.

I see. Thanks for the explanation!

Back to comp.programming.threads | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Re: Who needs acquire semantics for read operations? Marcel Müller <news.5.maazl@spamgourmet.org> - 2012-09-01 19:24 +0200
  Re: Who needs acquire semantics for read operations? Rani Sharoni <ranisharoni75@gmail.com> - 2012-09-02 00:10 -0700
    Re: Who needs acquire semantics for read operations? Marcel Müller <news.5.maazl@spamgourmet.org> - 2012-09-02 10:13 +0200
  Re: Who needs acquire semantics for read operations? Václav Zeman <v.haisman@sh.cvut.cz> - 2012-09-04 04:31 -0700
    Re: Who needs acquire semantics for read operations? Marcel Müller <news.5.maazl@spamgourmet.com> - 2012-09-04 15:24 +0200
      Re: Who needs acquire semantics for read operations? Rani Sharoni <ranisharoni75@gmail.com> - 2012-09-04 23:41 -0700
  Re: Who needs acquire semantics for read operations? Toby Douglass <a@b.com> - 2012-09-10 09:41 +0200

csiph-web