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 17:29:43 -0400 Organization: A noiseless patient Spider Lines: 79 Message-ID: <3333ab88612e6ca-ca2d9@gmail.com> References: <94eafd27-6aba-4a17-9403-d42912312e6c@googlegroups.com> <0.8f83cddfeac55b9f2de1.20120705232249BST.87k3yhalvq.fsf@bsb.me.uk> <7ee0b658ce2dc96-3111f@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="24646"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18nYVssnNMuevvkaG/zA/I3" User-Agent: nn 6.7.3 Content-Length: 2844 Cancel-Lock: sha1:pFaTlxES/EU4YYzRxMCSJqkS8fk= Xref: csiph.com comp.lang.c:23130 comp.programming.threads:943 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. > >>>Threaded code is a de-facto reality in today's multi-core environment. > >>>Save for the embedded sector, most systems will run threads in > >>>parallelo, and that is that. > >> > >>Only if you incorporate threads in your code either explicitly or > >>implicitly with something like OpenMP. > > > >Well, sure, but I'd like to think that multithreaded applications will > >be popular. It helps to improve the interactivity of applications > >with a GUI frontend for one thing, never mind what you can do with > >message-passing interfaces or asynchronus network I/O threads. > > There already are. Yes. There are many examples of such code. > >>>C has to recognize this watershed moment > >>>in the refinement of the language. > >> > >>It has. > > > >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. > >>>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. Regards, Uncle Steve -- The moon has never been closer.