<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Once upon a time, on 02/07/2013 01:46
PM to be precise, Jonas Maebe said:<br>
</div>
<blockquote
cite="mid:5FD558E7-705E-4EFB-BD10-32FD0CED120F@elis.ugent.be"
type="cite"><br>
<div>
<div>On 07 Feb 2013, at 13:39, Ewald wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite"><span class="Apple-style-span"
style="border-collapse: separate; color: rgb(0, 0, 0);
font-family: Monaco; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: 2; text-align: -webkit-auto;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px;
-webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px;
-webkit-text-decorations-in-effect: none;
-webkit-text-size-adjust: auto; -webkit-text-stroke-width:
0px; font-size: medium; "><span class="Apple-style-span"
style="font-family: monospace; ">Well, I always thought
that the InterLoackedCompareExchange boiles down<br>
to [**]<br>
.Lock CMPXCHG<br>
<br>
Or something quite like that. The `.Lock` there is the
important part<br>
since this does insure a memory barier.</span></span></blockquote>
</div>
<br>
<div>It's only a memory barrier if you don't use SSE (or
write-combined memory, but that's generally only the case for
memory mapped video memory or so, and more of an issue for
kernel mode code than for user space). </div>
</blockquote>
Alright, this is getting interesting ;-) Yet I wonder:
InterlockedCompareExchange is atomic, then you need to find a way to
make sure that only one processor core (one thread in general) is
accessing the memory that contains the integer/pointer. So, since
InterlockedCompareExchange does not necessarily makes use of a
memory barrier, how could it be done?<br>
<br>
Also, in case I misunderstood you and you are trying to say that if
I write using some instruction to a part of memory that contains or
is contained the integer/pointer (so there is some memory overlap)
then yes, I agree and it isn't a memory barrier anymore. But then
again, who writes data to a locking variable other then the code
that does the locking? (same goes for a simple `lock:= 5;` for
example)<br>
<br>
<blockquote
cite="mid:5FD558E7-705E-4EFB-BD10-32FD0CED120F@elis.ugent.be"
type="cite">
<div>Furthermore, FPC supports many more architectures than just
x86, and on (virtually?) all other platforms the instructions
for atomic accesses do not automatically imply any kind of
memory barrier.</div>
</blockquote>
Of course, I only used this piece of pseudo-assembly since it
conveys the message enough to understand each other.<br>
<br>
<pre class="moz-signature" cols="72">--
Ewald
</pre>
</body>
</html>