>> I use volatile for source code documentation only. That about how usefullYou could use volatile and cross your fingers, or put it "all" in a mutex...
>> 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 );
movl 4(%esp), %eax
movl 8(%esp), %ecx
movl %ecx, (%eax)
; sfence may be needed right here on future x86
movl $1, 4(%eax)
/* 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 thoseNow the compiler doesn't even have a chance to reorder anything.
> It seems reasonable to me, and it's consistent with another posting I justYeah, 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
> Unfortunately, pragmas areThat'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.
> similar idea is something like Microsoft's attributes, which, oddly
> 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.