Talk About Network

Google


Register and Login
Nick
Password
Register create new account Sign up is FREE and you can post replies, new topics, bookmark posts and more!
Recover lost password


Programming > Programming Threads > Re: threads vs ...
Latest [ Topics | Posts ] Archive Post A New Topic Post a Reply
<< Topic < Post Post 7 of 7 Topic 4053 of 4146
Post > Topic >>

Re: threads vs memory layout

by "Chris M. Thomasson" <no@[EMAIL PROTECTED] > Oct 7, 2008 at 09:32 AM

"Chris M. Thomasson" <no@[EMAIL PROTECTED]
> wrote in message 
news:5YLGk.29873$gY7.19956@[EMAIL PROTECTED]
> "Hallvard B Furuseth" <h.b.furuseth@[EMAIL PROTECTED]
> wrote in message 
> news:hbf.20081007bpkh@[EMAIL PROTECTED]
>> Hello again...  thanks for the answers so far:
>>
>> Dave Butenhof writes:
>>>Hallvard B Furuseth wrote:
>>>> What do POSIX and other thread APIs have to say about memory layout
>>>> of data accessed by different treads?  E.g.:
>>>>
>>>>     struct Foo {
>>>>         pthread_mutex_t ma, mb;
>>>>         int a, b; /* protected by ma and mb respectively */
>>>>         int c; /* not mutex-protected, only accessed by 1 thread */
>>>>     };
>>> (...)
>>> Generally int will be safe. Although on some machines, an UNALIGNED
int
>>> is legal but not necessarily atomic.
>>
>>> Both C and C++ are working now on detailed memory models that will
nail
>>> down standard and ****table answers to this sort of
>>> question. Unfortunately it's all well below the level that could be
>>> resolved in POSIX.
>>>
>>> As David Schwartz suggested, however, you're generally going to be
>>> better off keeping independently accessed data as "distinct objects"
>>> rather than compacting them into a common container. If you keep them
>>> distinctly separate, you have a much better chance that your code, the
>>> compiler, the memory allocator in your runtime, and the hardware will
>>> all get along.
>>
>> Makes sense.  What would you do if you want data structures with
>> differently-protected data in the same struct though?
>
>
> Here is possible contrived solution:
>
> struct data {
>  int part1;
>  char l2pad1[L2_CACHE_LINE_SIZE - sizeof(int)];
>  int part2;
>  char l2pad2[L2_CACHE_LINE_SIZE - sizeof(int)];
>  int part3;
>  char l2pad3[L2_CACHE_LINE_SIZE - sizeof(int)];
> };
>
>
> If you align this struct on a cache line boundary `data::part1/2/3' will

> never be false-shared with each other.
[...]


A much better solution would be to do something like:

union data_l2pad {
  int data;
  char l2pad[L2_CACHE_LINE_SIZE];
};

struct data {
  union data_l2pad part1;
  union data_l2pad part2;
  union data_l2pad part3;
};


:^)
 




 7 Posts in Topic:
threads vs memory layout
Hallvard B Furuseth <h  2008-09-25 22:43:10 
Re: threads vs memory layout
David Schwartz <davids  2008-09-25 13:47:32 
Re: threads vs memory layout
Dave Butenhof <david.b  2008-09-26 06:25:06 
Re: threads vs memory layout
"Sergey P. Derevyago  2008-10-03 18:30:17 
Re: threads vs memory layout
Hallvard B Furuseth <h  2008-10-07 15:48:42 
Re: threads vs memory layout
"Chris M. Thomasson&  2008-10-07 09:24:06 
Re: threads vs memory layout
"Chris M. Thomasson&  2008-10-07 09:32:47 

Post A Reply:
  Go here to Signup

AddThis Feed Button


About - Advertising - Contact - Frequently Asked Questions - Privacy Policy - Terms of Use - Signup

Contact
tan12V112 Sat Nov 22 9:14:24 CST 2008.