Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Uncle Steve Newsgroups: comp.lang.c,comp.programming.threads Subject: Re: Clarification on the applicability of compile-time optimization to a struct variable which encompasses a mixture of fields declared as volatile and non-volatile individually Date: Fri, 06 Jul 2012 19:55:07 -0400 Organization: A noiseless patient Spider Lines: 76 Message-ID: References: <7ee0b658ce2dc96-3111f@gmail.com> <3333ab88612e6ca-ca2d9@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Injection-Info: mx04.eternal-september.org; posting-host="M1JqkNNJU2aX/HiSUuiK1A"; logging-data="26996"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+jmG6v9OZFMp21pcJz1yJ3" User-Agent: nn 6.7.3 Content-Length: 2790 Cancel-Lock: sha1:Qp16EixH/weO6EALyV2Y0iU3EK8= Xref: csiph.com comp.lang.c:23139 comp.programming.threads:945 On Sat, Jul 07, 2012 at 03:50:59PM +1200, Ian Collins wrote: > On 07/ 7/12 09:29 AM, Uncle Steve wrote: > >On Sat, Jul 07, 2012 at 12:37:59PM +1200, Ian Collins wrote: > >>On 07/ 7/12 08:27 AM, Uncle Steve wrote: > >>>On Sat, Jul 07, 2012 at 11:29:02AM +1200, Ian Collins wrote: > >>>>On 07/ 7/12 06:33 AM, Uncle Steve wrote: > >>>>> > >>>>>Is there are C standard threading framework? > >>>> > >>>>Yes, read C11. If you are familiar with pthreads, you'll see where most > >>>>of the new primitives originate. > >>> > >>>Well, I don't follow gcc development, so I don't know when those > >>>features will be available on my system. > >> > >>Then use your platform's native threading primitives. > > > >Doing so would incur a performance penalty in comparison to my > >synchronization primitives in some circumstances. > > In other words, correctness would incur a performance penalty in > comparison to your synchronization primitives in some circumstances. You probably shouldn't be using google translate to massage my code into something you can understand. It doesn't work like that. > >>>O.K., so do nested structure elements inherit the parent structure's > >>>volatile attribute? > >> > >>A volatile T is a volatile T no matter what it contains. > > > >Look. In threaded applications, the truth associated with the value > >associated with certain variables can be somewhat indeterminate. If > >that's true in your code, you might want to be aware of it. > > If I could parse that, I'd respond to it. Yeah well it happens. > >>>>>While the specifics of an implementation within a given operating > >>>>>system are not C issues, certain common optimizations can be a problem > >>>>>with certain algorithms, and so there ought to be a C solution to the > >>>>>problem. What is it about the volatile attribute that makes it > >>>>>insufficient in your mind to the problem presented by threaded code? > >>>> > >>>>Given you are the one going against conventional wisdom, what in your > >>>>mind makes volatile a solution to the problem presented by threaded > >>>>code? > >>>> > >>>>In addition, what is "the problem presented by threaded code"? > >>> > >>>Well, code optimization from global CSE might eliminate memory > >>>accesses to variable that could be modified by other threads in ways > >>>that affect the algorithm. Depends of the code. > >> > >>If the code depends on volatile, it is broken. Use the atomics or > >>synchronisation primitives provided by the language or platform. They > >>exist for a reason. > > > >You aren't listening to me. > > You aren't making much sense. > > An example of you your synchronization primitives would clear things up. Sorry, you're going to have to wait. Regards, Uncle Steve -- The moon has never been closer.