Am 12.11.2023 um 21:46 schrieb Chris M. Thomasson:

> Yet, you missed it? Actually, I am not quite sure how to parse your
> response. I have not had the free time to port your code over to a
> Relacy test unit, yet...

Do you really think your Relacy would have helped with my missing "!"
with the initializtion - at a point where I didn't any synchronization
at all ?

On 11/14/2023 1:04 AM, Bonita Montero wrote:
> Am 12.11.2023 um 21:46 schrieb Chris M. Thomasson:
>
>> Yet, you missed it? Actually, I am not quite sure how to parse your
>> response. I have not had the free time to port your code over to a
>> Relacy test unit, yet...
>
> Do you really think your Relacy would have helped with my missing "!"
> with the initializtion - at a point where I didn't any synchronization
> at all ?
>
>

My Relacy?

Humm... Btw, my friend created it. Fwiw, I even helped him find some
interesting issues it had during its very early phase. I found a couple
of bugs in Relacy! lol. Anyway, your missing "!"? Huh?

Am 14.11.2023 um 10:21 schrieb Chris M. Thomasson:

> My Relacy?

Because you love it so much beyond necessity.

> Humm... Btw, my friend created it. Fwiw, I even helped him find some
> interesting issues it had during its very early phase. I found a couple
> of bugs in Relacy! lol. Anyway, your missing "!"? Huh?

My monitor is only 230 lines of code and easy to understand; no
necessity for Relacy. And I'm using my readers-writer-lock with
configurable priority for writers and readers for years without
having applied Relacy to it.

On 11/14/2023 2:00 AM, Bonita Montero wrote:
> Am 14.11.2023 um 10:21 schrieb Chris M. Thomasson:
>
>> My Relacy?
>
> Because you love it so much beyond necessity.
>
>> Humm... Btw, my friend created it. Fwiw, I even helped him find some
>> interesting issues it had during its very early phase. I found a
>> couple of bugs in Relacy! lol. Anyway, your missing "!"? Huh?
>
> My monitor is only 230 lines of code and easy to understand; no
> necessity for Relacy.

So, you are finished with any future on the fly corrections, right?

> And I'm using my readers-writer-lock with
> configurable priority for writers and readers for years without
> having applied Relacy to it.
>

Am 14.11.2023 um 11:08 schrieb Chris M. Thomasson:

> So, you are finished with any future on the fly corrections, right?

I'm currently not missing anything with the code.

Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> writes:
>Kaz Kylheku wrote:
>> On 2023-11-13, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:
>>> Kaz Kylheku wrote:
>>>> If you're using POSIX mutexes and conditions, you should call
>>>> pthread_cond_signal and pthread_cond_broadcast outside of the mutex,
>>>> whenever possible.
>>> This is recommended against by the standard for the same reason why Java
>>> implements Hoare monitor behavior. Citation:
>>>
>>> "
>>> The pthread_cond_broadcast() or pthread_cond_signal() functions may be
>>> called by a thread whether or not it currently owns the mutex that
>>> threads calling pthread_cond_wait() or pthread_cond_timedwait() have
>>> associated with the condition variable during their waits; however, if
>>> predictable scheduling behavior is required, then that mutex shall be
>>> locked by the thread calling pthread_cond_broadcast() or
>>> pthread_cond_signal().
>>> "
>>
>> But that text is stupid/defective, because you will not actually get
>> predictable scheduling behavior just by doing that.
>
>This is POSIX text that IIRC was a compromise with real-time (RT) guys.
>Java has thread priorities so it is formally relevant (could be relevant
>in some implementations, too; did not really check). RT guys don't like
>condvars in principle as they are a "gateway drug" to all kinds of prio
>inversions so this was a compromise that permitted the condvar to get to
>POSIX. The meaning of the spec is to prevent priority inversion when
>running on one CPU. An example problematic scenario is as follows:
>
>1. Higher-prio thread A grabs mutex and starts waiting for an event
>(say, posted to a queue that's currently empty). The mutex is released
>at this time to allow posting the event (the standard behavior of
>pthread_cond_wait()).
>2. Now that the A is not runnable, a lower-prio thread B can also run
>and suppose it also wants event from same queue.
>3. Thread C grabs mutex, posts event to the queue, releases the mutex
>4. Before thread C manages to signal the condvar (and by that wake up
>thread A), thread B grabs the lock and steals the event. Higher-prio
>thread A stays waiting for the event -- which is what RT guys hate.
>
>With the behavior recommended by the standard, thread C will first
>notify condvar, by that making thread A runnable and thread A will grab
>the event.

Clearly the application should have used a queue per priority in
this case.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 14.11.2023 um 06:21 schrieb Chris M. Thomasson:
>
>> You mean a word wrt the arch, or uint64_t on a 32-bit system?
>
>itemOutput first was a atomic_uint64_t and now is a uint64_t.
>The atomicwasn't necessary because itemOutput is accessed within
>a mutex access, i.e. it is surrounded with a lock() and unlock()
>which itself have a acquire and release behaviour, so I itemOutput
>doesn't need to be atomic.

In most commonly used architectures a 64-bit load is single-copy
atomic regardless of any external synchronization (e.g. a mutex,
spin-lock or semaphore).

Am 14.11.2023 um 16:18 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 14.11.2023 um 06:21 schrieb Chris M. Thomasson:
>>
>>> You mean a word wrt the arch, or uint64_t on a 32-bit system?
>>
>> itemOutput first was a atomic_uint64_t and now is a uint64_t.
>> The atomicwasn't necessary because itemOutput is accessed within
>> a mutex access, i.e. it is surrounded with a lock() and unlock()
>> which itself have a acquire and release behaviour, so I itemOutput
>> doesn't need to be atomic.
>
> In most commonly used architectures a 64-bit load is single-copy
> atomic regardless of any external synchronization (e.g. a mutex,
> spin-lock or semaphore).

Maybe, but you can't rely on that. If you have a 32 bit platform
there's not always an easy way to have atomic 64 bit stores.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 14.11.2023 um 16:18 schrieb Scott Lurndal:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> Am 14.11.2023 um 06:21 schrieb Chris M. Thomasson:
>>>
>>>> You mean a word wrt the arch, or uint64_t on a 32-bit system?
>>>
>>> itemOutput first was a atomic_uint64_t and now is a uint64_t.
>>> The atomicwasn't necessary because itemOutput is accessed within
>>> a mutex access, i.e. it is surrounded with a lock() and unlock()
>>> which itself have a acquire and release behaviour, so I itemOutput
>>> doesn't need to be atomic.
>>
>> In most commonly used architectures a 64-bit load is single-copy
>> atomic regardless of any external synchronization (e.g. a mutex,
>> spin-lock or semaphore).
>
>Maybe, but you can't rely on that. If you have a 32 bit platform

32-bit platform is somewhat uncommon (outside of specialty microcontrollers
like the Cortex-M7).

I'm not aware of any 32-bit platform that supports 64-bit
accesses (other than via two 32-bit accesses).

With x86_64 and AArch64 you _can_ rely on it. And we do.

Am 14.11.2023 um 17:09 schrieb Scott Lurndal:

> I'm not aware of any 32-bit platform that supports 64-bit
> accesses (other than via two 32-bit accesses).

If I do a 64 bit atomic store with MSVC or clang-cl on a 32 bit
platform it stores the value in the stack, loads it with SSE and
stores it atomically.

Am 14.11.2023 um 17:41 schrieb Bonita Montero:

> If I do a 64 bit atomic store with MSVC or clang-cl on a 32 bit
> platform it stores the value in the stack, loads it with SSE and
> stores it atomically.

I just asked myself what MSVC does if I have a 64 bit atomic store
and I compile with -arch:IA32, i.e. without SSE. I compiled the
following function:

#include <atomic>

using namespace std;

void fn( atomic_uint64_t &a, uint64_t v )
{ a.store( v, memory_order_relaxed );
}

This is the generated code:

?fn@@YAXAAU?$atomic@_K@std@@_K@Z PROC
mov eax, DWORD PTR _v$[esp-4]
mov ecx, DWORD PTR _v$[esp]
mov DWORD PTR tv135[esp-4], eax
mov eax, DWORD PTR _a$[esp-4]
mov DWORD PTR tv135[esp], ecx
fild QWORD PTR tv135[esp-4]
fistp QWORD PTR [eax]
ret 0
?fn@@YAXAAU?$atomic@_K@std@@_K@Z ENDP

Interestingly the resulting temporary floating point value isn't
chopped according to the set precision in the x87 FPU control word,
so we have all of the 64 bits inside the mantissa, of course with
a shift.

On 11/14/2023 8:09 AM, Scott Lurndal wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 14.11.2023 um 16:18 schrieb Scott Lurndal:
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>> Am 14.11.2023 um 06:21 schrieb Chris M. Thomasson:
>>>>
>>>>> You mean a word wrt the arch, or uint64_t on a 32-bit system?
>>>>
>>>> itemOutput first was a atomic_uint64_t and now is a uint64_t.
>>>> The atomicwasn't necessary because itemOutput is accessed within
>>>> a mutex access, i.e. it is surrounded with a lock() and unlock()
>>>> which itself have a acquire and release behaviour, so I itemOutput
>>>> doesn't need to be atomic.
>>>
>>> In most commonly used architectures a 64-bit load is single-copy
>>> atomic regardless of any external synchronization (e.g. a mutex,
>>> spin-lock or semaphore).
>>
>> Maybe, but you can't rely on that. If you have a 32 bit platform
>
> 32-bit platform is somewhat uncommon (outside of specialty microcontrollers
> like the Cortex-M7).
>
> I'm not aware of any 32-bit platform that supports 64-bit
> accesses (other than via two 32-bit accesses).

Well, we have cmpxchg8b on 32-bit Intel...

>
> With x86_64 and AArch64 you _can_ rely on it. And we do.
>
>
>

On 11/14/2023 2:23 AM, Bonita Montero wrote:
> Am 14.11.2023 um 11:08 schrieb Chris M. Thomasson:
>
>> So, you are finished with any future on the fly corrections, right?
>
> I'm currently not missing anything with the code.

Okay, can you please make a new post that contains the finished code?

Thanks.

On 11/14/2023 12:27 PM, Chris M. Thomasson wrote:
> On 11/14/2023 2:23 AM, Bonita Montero wrote:
>> Am 14.11.2023 um 11:08 schrieb Chris M. Thomasson:
>>
>>> So, you are finished with any future on the fly corrections, right?
>>
>> I'm currently not missing anything with the code.
>
> Okay, can you please make a new post that contains the finished code?
>
> Thanks.

Brand new thread:

Bonita Monitor, Fin...

Show the code, an I will work with that. Okay?

On 11/14/2023 12:25 PM, Chris M. Thomasson wrote:
> On 11/14/2023 8:09 AM, Scott Lurndal wrote:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> Am 14.11.2023 um 16:18 schrieb Scott Lurndal:
>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>> Am 14.11.2023 um 06:21 schrieb Chris M. Thomasson:
>>>>>
>>>>>> You mean a word wrt the arch, or uint64_t on a 32-bit system?
>>>>>
>>>>> itemOutput first was a atomic_uint64_t and now is a uint64_t.
>>>>> The atomicwasn't necessary because itemOutput is accessed within
>>>>> a mutex access, i.e. it is surrounded with a lock() and unlock()
>>>>> which itself have a acquire and release behaviour, so I itemOutput
>>>>> doesn't need to be atomic.
>>>>
>>>> In most commonly used architectures a 64-bit load is single-copy
>>>> atomic regardless of any external synchronization (e.g. a mutex,
>>>> spin-lock or semaphore).
>>>
>>> Maybe, but you can't rely on that. If you have a 32 bit platform
>>
>>   32-bit platform is somewhat uncommon (outside of specialty
>> microcontrollers
>> like the Cortex-M7).
>>
>>   I'm not aware of any 32-bit platform that supports 64-bit
>> accesses (other than via two 32-bit accesses).
>
> Well, we have cmpxchg8b on 32-bit Intel...

Also, check this out:

https://groups.google.com/g/comp.lang.asm.x86/c/FScbTaQEYLc

:^)

>
>>
>>   With x86_64 and AArch64 you _can_ rely on it.   And we do.
>>
>>
>>
>

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>On 11/14/2023 8:09 AM, Scott Lurndal wrote:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> Am 14.11.2023 um 16:18 schrieb Scott Lurndal:
>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>> Am 14.11.2023 um 06:21 schrieb Chris M. Thomasson:
>>>>>
>>>>>> You mean a word wrt the arch, or uint64_t on a 32-bit system?
>>>>>
>>>>> itemOutput first was a atomic_uint64_t and now is a uint64_t.
>>>>> The atomicwasn't necessary because itemOutput is accessed within
>>>>> a mutex access, i.e. it is surrounded with a lock() and unlock()
>>>>> which itself have a acquire and release behaviour, so I itemOutput
>>>>> doesn't need to be atomic.
>>>>
>>>> In most commonly used architectures a 64-bit load is single-copy
>>>> atomic regardless of any external synchronization (e.g. a mutex,
>>>> spin-lock or semaphore).
>>>
>>> Maybe, but you can't rely on that. If you have a 32 bit platform
>>
>> 32-bit platform is somewhat uncommon (outside of specialty microcontrollers
>> like the Cortex-M7).
>>
>> I'm not aware of any 32-bit platform that supports 64-bit
>> accesses (other than via two 32-bit accesses).
>
>Well, we have cmpxchg8b on 32-bit Intel...

For which a single-copy atomic semantic property is implicit
in the operation.

As BM pointed out, once SSE et al showed up, there was a way to
do some 64-bit loads. Not sure they're architecturally
required to be single-copy atomic, however.

Kaz Kylheku wrote:
> On 2023-11-14, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:
>> Kaz Kylheku wrote:
>>> Because of the situation that the thread which was signaled is
>>> trying to acquire the mutex, which, stupidly, the signaling thread
>>> is still holding. So, oops, back it goes into suspended state, and we
>>> have to context switch to the mutex holder which has to release the
>>> mutex and then switch to that signaled thread again.
>>>
>> Please see my response to your other post. "as-if" calling of
>> pthread_mutex_lock does not prescribe actually calling it. Nothing in
>> the standard prevents pthread_cond_signal from doing all the job of
>> stuffing the unblocked threads to the mutex waiting list in accordance
>> with some scheduling policy.
>
> Have you noticed how no mutex appears in the pthread_cond_signal API?
>
Of course but so what? Nothing prevents the implementation from listing
the temporarily released mutices of the waiting pthread_cond_wait
callers in the cond var where pthread_cond_signal can access them.

Or, possibly even better, keeping a pointer to them with the threads
waiting for the condvar (there can only be at most one such temporarily
released mutex per the waiting thread). And the threads waiting for the
condvar are accessible for the pthread_cond_signal according to the spec.

Scott Lurndal wrote:
> Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> writes:
>> Kaz Kylheku wrote:
>>> On 2023-11-13, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:
>>>> Kaz Kylheku wrote:
>>>>> If you're using POSIX mutexes and conditions, you should call
>>>>> pthread_cond_signal and pthread_cond_broadcast outside of the mutex,
>>>>> whenever possible.
>>>> This is recommended against by the standard for the same reason why Java
>>>> implements Hoare monitor behavior. Citation:
>>>>
>>>> "
>>>> The pthread_cond_broadcast() or pthread_cond_signal() functions may be
>>>> called by a thread whether or not it currently owns the mutex that
>>>> threads calling pthread_cond_wait() or pthread_cond_timedwait() have
>>>> associated with the condition variable during their waits; however, if
>>>> predictable scheduling behavior is required, then that mutex shall be
>>>> locked by the thread calling pthread_cond_broadcast() or
>>>> pthread_cond_signal().
>>>> "
>>>
>>> But that text is stupid/defective, because you will not actually get
>>> predictable scheduling behavior just by doing that.
>>
>> This is POSIX text that IIRC was a compromise with real-time (RT) guys.
>> Java has thread priorities so it is formally relevant (could be relevant
>> in some implementations, too; did not really check). RT guys don't like
>> condvars in principle as they are a "gateway drug" to all kinds of prio
>> inversions so this was a compromise that permitted the condvar to get to
>> POSIX. The meaning of the spec is to prevent priority inversion when
>> running on one CPU. An example problematic scenario is as follows:
>>
>> 1. Higher-prio thread A grabs mutex and starts waiting for an event
>> (say, posted to a queue that's currently empty). The mutex is released
>> at this time to allow posting the event (the standard behavior of
>> pthread_cond_wait()).
>> 2. Now that the A is not runnable, a lower-prio thread B can also run
>> and suppose it also wants event from same queue.
>> 3. Thread C grabs mutex, posts event to the queue, releases the mutex
>> 4. Before thread C manages to signal the condvar (and by that wake up
>> thread A), thread B grabs the lock and steals the event. Higher-prio
>> thread A stays waiting for the event -- which is what RT guys hate.
>>
>> With the behavior recommended by the standard, thread C will first
>> notify condvar, by that making thread A runnable and thread A will grab
>> the event.
>
> Clearly the application should have used a queue per priority in
> this case.
This has been an alternative for a while but traditionally RT is built
on the threads of different prios as opposed to the resources of
different prios.

There are reasons for this, too: one I remember is that the ordering
becomes better defined. (Just as an example, imagine that the events
posted on the queue are work permits of some kind. The policy is that
while higher-prio thread is waiting for a work permit, no lower-prio
thread shall get a permit).

Kaz Kylheku wrote:
> On 2023-11-14, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:
>> "as-if" and "according to the scheduling policy (if applicable)" here
>> are important. The standard intent may be to permit only the threads
>> that are "unblocked" contend for the mutex -- as opposed to all
>> non-blocked threads.
>
> It's possible that only one thread is unblocked by a
> pthread_cond_signal. It takes at least two parties to contend for
> something.
>
My point was that the "unblocked" thread could be the thread that "won"
the contention. "as-if" there meant that the threads didn't really need
to be all woken up / unblocked and start contending; but the contention
could be resolved according to the scheduling policy (the same one that
would be applied if they were actually running and contending for the
mutex, without any waiting for the condvar) within the signal call.

Chris M. Thomasson wrote:
> On 11/13/2023 9:28 PM, Chris M. Thomasson wrote:
>> On 11/13/2023 7:27 PM, Kaz Kylheku wrote:
>>> On 2023-11-14, Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>
>>> wrote:
>>>> "as-if" and "according to the scheduling policy (if applicable)" here
>>>> are important. The standard intent may be to permit only the threads
>>>> that are "unblocked" contend for the mutex -- as opposed to all
>>>> non-blocked threads.
>>>
>>> It's possible that only one thread is unblocked by a
>>> pthread_cond_signal. It takes at least two parties to contend for
>>> something.
>>>
>>
>> A signalling thread does its thing while holding the mutex... Well, it
>> hears the following playing in the background:
>>
>> https://youtu.be/7YvAYIJSSZY
>
> A condvar that cannot signal/broadcast from outside of a held mutex is
> broken by default.
It can, it's just that the desired scheduling policy cannot be
*effectively* applied if a program signal outside of that mutex.

E.g. in some scenario a higher-prio thread could stay indefinitely
starved by the lower-prio thread, regardless of the thread library
implementation.

Bonita Montero wrote:
> Am 09.11.2023 um 06:48 schrieb Chris M. Thomasson:
>> On 11/8/2023 9:45 PM, Bonita Montero wrote:
>>> Am 09.11.2023 um 06:44 schrieb Chris M. Thomasson:
>>>
>>>> Wait morphing is not in the realm of the compiler. It's in the kernel.
>>>
>>> Read this:
>>> https://stackoverflow.com/questions/45163701/which-os-platforms-implement-wait-morphing-optimization
>>>
>>
>> Wait morphing can be highly beneficial.
>
> Wait morphing isn't necessary under Win32 since you can wait
> for the mutexe's binary semaphore and for the condvar's counting
> semaphore in one step with WaitForMultipleObjects. Unfortunately
> there's nothing under Linux like that.
>
Not true. A Linux program can wait for any number of eventfd semaphores
that can be used as either binary or a counting one.

Am 14.11.2023 um 21:27 schrieb Chris M. Thomasson:
> On 11/14/2023 2:23 AM, Bonita Montero wrote:
>> Am 14.11.2023 um 11:08 schrieb Chris M. Thomasson:
>>
>>> So, you are finished with any future on the fly corrections, right?
>>
>> I'm currently not missing anything with the code.
>
> Okay, can you please make a new post that contains the finished code?

I already posted the finished code in two parts with this little
correction (missing "!"). The xhandle.h is still the same.

Am 14.11.2023 um 21:25 schrieb Chris M. Thomasson:

> Well, we have cmpxchg8b on 32-bit Intel...

That's what I also thought, i.e. you can make a 64 bit store with that.
But that's for sure much slower than the trick with the x87-FPU I've
shown.

Am 15.11.2023 um 03:10 schrieb Pavel:
> Bonita Montero wrote:
>> Am 09.11.2023 um 06:48 schrieb Chris M. Thomasson:
>>> On 11/8/2023 9:45 PM, Bonita Montero wrote:
>>>> Am 09.11.2023 um 06:44 schrieb Chris M. Thomasson:
>>>>
>>>>> Wait morphing is not in the realm of the compiler. It's in the kernel.
>>>>
>>>> Read this:
>>>> https://stackoverflow.com/questions/45163701/which-os-platforms-implement-wait-morphing-optimization
>>>
>>> Wait morphing can be highly beneficial.
>>
>> Wait morphing isn't necessary under Win32 since you can wait
>> for the mutexe's binary semaphore and for the condvar's counting
>> semaphore in one step with WaitForMultipleObjects. Unfortunately
>> there's nothing under Linux like that.
>>
> Not true. A Linux program can wait for any number of eventfd semaphores
> that can be used as either binary or a counting one.

An eventfd can be a semaphore, but only one semaphore and not a set
like SysV semaphores. You can wait for multiple semaphores with poll
or select, but a change on one semaphore releases the waiting thread
whereas with Win32 you can wait for all conditions to be met at once.

On 11/14/2023 2:50 PM, Scott Lurndal wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 11/14/2023 8:09 AM, Scott Lurndal wrote:
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>> Am 14.11.2023 um 16:18 schrieb Scott Lurndal:
>>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>>> Am 14.11.2023 um 06:21 schrieb Chris M. Thomasson:
>>>>>>
>>>>>>> You mean a word wrt the arch, or uint64_t on a 32-bit system?
>>>>>>
>>>>>> itemOutput first was a atomic_uint64_t and now is a uint64_t.
>>>>>> The atomicwasn't necessary because itemOutput is accessed within
>>>>>> a mutex access, i.e. it is surrounded with a lock() and unlock()
>>>>>> which itself have a acquire and release behaviour, so I itemOutput
>>>>>> doesn't need to be atomic.
>>>>>
>>>>> In most commonly used architectures a 64-bit load is single-copy
>>>>> atomic regardless of any external synchronization (e.g. a mutex,
>>>>> spin-lock or semaphore).
>>>>
>>>> Maybe, but you can't rely on that. If you have a 32 bit platform
>>>
>>> 32-bit platform is somewhat uncommon (outside of specialty microcontrollers
>>> like the Cortex-M7).
>>>
>>> I'm not aware of any 32-bit platform that supports 64-bit
>>> accesses (other than via two 32-bit accesses).
>>
>> Well, we have cmpxchg8b on 32-bit Intel...
>
> For which a single-copy atomic semantic property is implicit
> in the operation.
>
> As BM pointed out, once SSE et al showed up, there was a way to
> do some 64-bit loads. Not sure they're architecturally
> required to be single-copy atomic, however.
>

Right! I am not sure about that either.