Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Alexander Terekhov Newsgroups: comp.programming.threads Subject: Re: Thread safe logging (or protecting global variables) Date: Thu, 15 Sep 2011 13:12:27 +0200 Organization: A noiseless patient Spider Lines: 51 Message-ID: <4E71DD9B.BC356E9@web.de> References: <49s9q.1564$8D1.58@newsfe19.ams2> <28d00de6-ff3f-429c-acea-62646656400f@r8g2000prd.googlegroups.com> <4E708D45.C98CF9DF@web.de> <17b0441f-0a8c-4c53-97e6-90e79cb7888d@z26g2000pre.googlegroups.com> Reply-To: terekhov@web.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: mx04.eternal-september.org; posting-host="MCbSEzW5qwGLFMNXJh39IQ"; logging-data="16588"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/3MkbwpLs+3A0b9ozZHp9Ufjx6JEl8+mk=" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en Cancel-Lock: sha1:cq4iEX0MQllhS99mPCePuue2xcg= Xref: x330-a1.tempe.blueboxinc.net comp.programming.threads:569 Joshua Maurice wrote: > > On Sep 14, 7:19 pm, "James" wrote: > > "Joshua Maurice" wrote in message > > > > news:17b0441f-0a8c-4c53-97e6-90e79cb7888d@z26g2000pre.googlegroups.com... > > > > [...] > > > > > First is that "InterlockedIncrement" probably does not provide memory > > > order guarantees, probably just like C++11 std::memory_order_relaxed. > > > > http://msdn.microsoft.com/en-us/library/ms683614(v=vs.85).aspx > > > > How do you explain the following quote: > > > > "This function generates a full memory barrier (or fence) to ensure that > > memory operations are completed in order." > > > > ? > > I explain it through my complete inability to read. > > So, do the interlocked functions act as a full barrier? As that's ill > defined without context, do they act at least as strong as a C++11 > std::memory_order_acq_rel memory operation? > > Is that Boost mailing list "post" authoritative? It raised some good > points, but the lack of proper punctuation makes me question it. To What do you mean by "authoritative"? ;-) Back in 2001 I was typing so fast that proper punctuation was just a hindrance. > quite, "also, Interlocked stuff does not formally provide memory synch > guaranties". The above msdn citation is about as formal as you get for > win32 AFAIK. I merely assumed it'd work as documented. Anyone actually > know if it doesn't? IIRC back in 2001 MS docs said absolutely nothing about memory fencing for interlocked stuff. Saying that "this function generates a full memory barrier (or fence) to ensure that memory operations are completed in order" isn't really helpful either because in the context of relaxed memory models a fully fenced RMW needs more than one fence. regards, alexander.