false sharing confusion!!

I know very badly the problem of false sharing.
Questions:
(1) There is a false sharing of 2 processors with 2 cache which can lead ONLY to inefficiency BUT NOT to bugs (unwanted rush conditions on not really shared adjacent data)
(2) There is a false sharing of core-2 Intels with two cores but one cache? This might lead to BUGS?!
(3) There is a false sharing of core duo with 2 cash (if they exist) which might be similar to case (1) ?
(4) In a C pthread program what directives or wahtever can I use to prevent at all this f..ng false sharing??
(5) please give me interesting links!

Thank you for support

moreover:
i found the chance of malfunctioning in a google forum for mutex use under Windows. Is that correct? What about POSIX?
Can we really have bad mutex or semaphore behaviour due to false sharing??

hey nobody answers??

Quote:

---

Originally Posted by mynickmynick

I know very badly the problem of false sharing.
Questions:
(1) There is a false sharing of 2 processors with 2 cache which can lead ONLY to inefficiency BUT NOT to bugs (unwanted rush conditions on not really shared adjacent data)
(2) There is a false sharing of core-2 Intels with two cores but one cache? This might lead to BUGS?!
(3) There is a false sharing of core duo with 2 cash (if they exist) which might be similar to case (1) ?
(4) In a C pthread program what directives or wahtever can I use to prevent at all this f..ng false sharing??
(5) please give me interesting links!

Thank you for support

---

1) Correct. If you have false sharing (which means, in case someeone else reads this thread, that two pieces of data used by different threads, are sharing the same cache-line) will only ever lead to inefficiency on a correctly working (aka "bug/errata free") processor. Also note that sharing data that is mostly being read is not a problem, so for example:

Code:

---

int *ptr[NUMTHREADS];

int main()
{
...
  for(i = 0; i < NUMTHREADS; i++)
  {
      ptr[i] = malloc(...);
  }
  // create threads...
  ...
  // wait for threads to end
  for(i = 0; i < NUMTHREADS; i++)
  {
      free(ptr[i]);
  }
}

---

As long as we don't re-allocate the ptr array members, it will not have any performance impact to share those ptr array members between threads, since they are not being written to.

2) Core2 processors may have a SHARED L2 cache (and Quad core AMD processors have shared L3 cache), but there is still a "close to the processor" L1 (and L2 in the AMD case) cache that is unshared. So you still get sharing there.

3) Explained in 2.

4) Depends on the compiler. A simple way is to make sure that all data structures that contain small amounts intended for sharing of data is aligned to a cache-line (32-128 bytes). Alternatively, have a different set of data for each processor, that is allocated dynamically (and at least 32 to 128 bytes long depending on cache-size), instead of using say a common "indexed per thread" structure.

5) Don't know of any links of the top of my head. I suspect there are comments on sharing data in the AMD and Intel "Performance optimization guide" documents.

--
Mats

Quote:

---

Originally Posted by mynickmynick

moreover:
i found the chance of malfunctioning in a google forum for mutex use under Windows. Is that correct? What about POSIX?
Can we really have bad mutex or semaphore behaviour due to false sharing??

---

Posting a link to that page would help.

In a processor that has errata (and I know that both AMD and Intel have had errata relating to caches and sharing behaviours at different times - however, almost all the time, these can be fixed trivially in the OS implementation, and they are normally detected before the processor hits the market and usually fixed in the next stepping of the processor).

It is obviously pretty pointless to have semaphores that don't work.

Whether POSIX is affected by any of such errata, and for which processors, under what conditions, etc, I can't really comment on. The errata are very often quite specific about what the conditions for the particular errata should affect the code. Normally, changing the location or adding some sort of sequencing operation to the code will fix these types of problems, and whilst not ideal for performance, fixes usually don't make it MUCH worse.

--
Mats