Path: csiph.com!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Ian Collins 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: Sat, 07 Jul 2012 15:50:59 +1200 Lines: 60 Message-ID: References: <94eafd27-6aba-4a17-9403-d42912312e6c@googlegroups.com> <0.8f83cddfeac55b9f2de1.20120705232249BST.87k3yhalvq.fsf@bsb.me.uk> <7ee0b658ce2dc96-3111f@gmail.com> <3333ab88612e6ca-ca2d9@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net ByawxfdhBNQf56B4Pdb72ARIOF3N+Q4IP6zpQ8Vljro1iBuEEeJPIEZsyVc+gi4fEc Cancel-Lock: sha1:H5JasTx2SLTS1ZaIUVCMi/XYl28= User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:12.0) Gecko/20120423 Thunderbird/12.0 In-Reply-To: <3333ab88612e6ca-ca2d9@gmail.com> Xref: csiph.com comp.lang.c:23138 comp.programming.threads:944 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. >>> 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. >>>>> 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. -- Ian Collins