|
 |
Newsgroups: comp.programming.threads
From: "SenderX" <x...@xxx.com>
Date: Fri, 4 Feb 2005 22:08:12 -0800
Local: Sat, Feb 5 2005 1:08 am
Subject: Re: Memory Barriers, Compiler Optimizations, etc.
>> I use volatile for source code documentation only. That about how usefull You could use volatile and cross your fingers, or put it "all" in a mutex... >> it >> really is wrt this kind of stuff. > So if you want to write something like this: > int data; > ... > data = 22; // set data to communicate to other threads > How do you ensure that the compiler doesn't invert the order of those But, we want a speedy lock-free solution, like your example shows. You could identify this code as a "critical-sequence" of operations and, IMHO, do it in assembly. I am starting to find that assembly language can be a lot more useful than C wrt lock-free programming in general; It eases my mind... lol. I have become more and more paranoid about this subject because the i686 version of my AppCore library is done. All that I have left to do is finish the documentation. People may start to use it because of the high-peformance its provides, and I want there experience to be a good one. So, I'll quickly scribble down an ad-hoc lock-free solution for your question in C and i686: /* C-style compile-time assertion for 32-bit cpu */ /* MUST be two "adjacent" words!!! */ } cs_t; /* "safely" produces data. Safe is good! */ extern void i686_cs_produce_data( cs_t*, int ); .globl i686_cs_produce_data i686_cs_produce_data: movl 4(%esp), %eax movl 8(%esp), %ecx movl %ecx, (%eax) ; sfence may be needed right here on future x86 movl $1, 4(%eax) ret /* abstract this cpu specific code into common api. */ /* now, a thread-safe version of your example in C */ cs_produce_data( &my_data, 22 ); >>> How do you ensure that the compiler doesn't invert the order of those Now the compiler doesn't even have a chance to reorder anything. > assignments? :) > It seems reasonable to me, and it's consistent with another posting I just Yeah, I thought it could be a simple and straight forward method for passing > made. In theory, you could get arbitrarily fine-grained with the > information you pass to the compilers this way. all sorts of critical information about your custom functions directly to the compiler. > Unfortunately, pragmas are That's what I thought. However, I think the idea, at least, justifies a > defined to be inherently platform-specific, and my guess is that it'd be > very difficult to get the C or C++ committees to standardize pragmas. thoughtful discussion in the C/C++ committees. > A Humm... > similar idea is something like Microsoft's attributes, which, oddly > enough, > might be easier push, because it's introducing something brand new rather > than changing the semantics of something that currently exists. You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||