Home » U++ Library support » U++ MT-multithreading and servers » Again ReadMemoryBarrier() etc
| Again ReadMemoryBarrier() etc [message #10418] |
Sun, 08 July 2007 13:09  |
|
|
Mirek
You dont need to use sfence and write Your own functions as it is now
There are intristics for this on both x86 ad x64
http://msdn2.microsoft.com/en-us/library/65tt87y8(VS.80).aspx
the _WriteBarrier function forces writes to memory to complete at the point of the call. After the call, other threads can access the memory without fear that the thread that made the call might have a pending write to the memory.
<intrin.h>
_ReadBarrier, _WriteBarrier, and _ReadWriteBarrier
|
|
|
|
| Re: Again ReadMemoryBarrier() etc [message #10431 is a reply to message #10418] |
Mon, 09 July 2007 09:49  |
 |
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
Sorry, but this is the complete misunderstanding of the issue from several points of view.
First of all, these intrinsics are about COMPILER reordering! The do not emit any instructions, they just tell the compiler not to perform certain optimizations.
Second, they are not available on GCC and they behave differently on previous MSC versions.
Third, lfence / sfence are SSE instructions and believe or not, we still have to support CPUs without SSE.
Fourth, the idea that "the _WriteBarrier function forces writes to memory to complete at the point of the call. After the call, other threads can access the memory without fear that the thread that made the call might have a pending write to the memory." is wrong as well, even if you would thing that it emits actual CPU write barrier. This is not what a write barrier does for you... (but your mistake is quite understandable, because I was under this false impression too a couple of months ago....)
Mirek
|
|
|
|
| Re: Again ReadMemoryBarrier() etc [message #10434 is a reply to message #10431] |
Mon, 09 July 2007 10:50 |
|
|
| luzr wrote on Mon, 09 July 2007 09:49 |
Sorry, but
Fourth, the idea that "the _WriteBarrier function forces writes to memory to complete at the point of the call. After the call, other threads can access the memory without fear that the thread that made the call might have a pending write to the memory." is wrong as well, even if you would thing that it emits actual CPU write barrier. This is not what a write barrier does for you... (but your mistake is quite understandable, because I was under this false impression too a couple of months ago....)
Mirek
|
This is not my mistake this is from MSDN info about how this instristic work.
Who has right You or Microsoft ? 
|
|
|
|
| Re: Again ReadMemoryBarrier() etc [message #10436 is a reply to message #10434] |
Mon, 09 July 2007 11:07 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| arturbac wrote on Mon, 09 July 2007 04:50 |
| luzr wrote on Mon, 09 July 2007 09:49 |
Sorry, but
Fourth, the idea that "the _WriteBarrier function forces writes to memory to complete at the point of the call. After the call, other threads can access the memory without fear that the thread that made the call might have a pending write to the memory." is wrong as well, even if you would thing that it emits actual CPU write barrier. This is not what a write barrier does for you... (but your mistake is quite understandable, because I was under this false impression too a couple of months ago....)
Mirek
|
This is not my mistake this is from MSDN info about how this instristic work.
Who has right You or Microsoft ?
|
Actually, Microsoft documentation is quite often wrong or misleading about MT issues...
Anyway, read more carefully into the link you posted:
| Quote: |
As part of its optimization algorithms, the Visual C++ compiler might reorder memory reads and writes in unpredictable ways between explicit accesses to a variable. As a result, the value of that variable might not have a predictable value between each explicit use of the variable. This could cause problems in multithreaded programming.
|
You can also look here:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=177456 1&SiteID=1
Mirek
|
|
|
|
|
|
Goto Forum:
Current Time: Fri Apr 19 17:12:12 CEST 2024
Total time taken to generate the page: 0.02455 seconds
|
Members
Pages
Help
Register
Login
Home
