Oleh,

You could well be right, but as you yourself admit, you don't know about other architectures.  As
Neil mentioned, we kinda busy right now. :-)

We're not going to remove a line of code that was explicitly added back in 1999 until we've thought it through,
and right now we have more pressing issues to address.

In the meantime, we will raise PR67271 to track this.  We believe me when we say that we do appreciate your
input.

Cheers,

Colin

Oleh Derevenko wrote:
> Hi Attilla
> 
>> I don't belive __mutex_smp_xchg() contains it's own  memory barrier. All ofthe
>>  other references to it call some form of memory barrier first. 
> 
> Let's have a look at your own (QNX) implementation of memory barrier.
> 
> #define __cpu_membarrier() ({ extern unsigned __cpu_flags; if(__cpu_flags & (1 << 15)) __asm__ __volatile__ ("mfence"); 
else __asm __volatile__("lock; orb $0,0(%esp)"); })
> 
> Now let's have a look at implementation of memory barrier in MSVC 2005
> 
> FORCEINLINE
> VOID
> MemoryBarrier (
>     VOID
>     )
> {
>     LONG Barrier;
>     __asm {
>         xchg Barrier, eax
>     }
> }
> 
> Now let's have a look at implementation of _smp_xchg()
> 
> static __inline int __attribute__((__unused__)) _smp_xchg(volatile unsigned *__dst, unsigned __src) {
> 	__asm__ __volatile__(
> 		"xchgl %0,%1"
> 		:"=r" (__src)
> 		:"m" (__atomic_fool_gcc(__dst)), "0" (__src)
> 		:"memory");
> 	return __src;
> }
> 
> Don't you see any similarities with memory barrier from MSVC?
> All the locked memory access instructions (the ones with "lock" prefix) are implicitly the memory barriers. 
> 
> Here is an excerpt from IA-32 Intel® Architecture Software Developer’s Manual (pay attention to the last paragraph).

> =============
> 7.2.4. Strengthening or Weakening the Memory Ordering Model
> The IA-32 architecture provides several mechanisms for strengthening or weakening the
> memory ordering model to handle special programming situations. These mechanisms include:
> • The I/O instructions, locking instructions, the LOCK prefix, and serializing instructions
> force stronger ordering on the processor.
> • The SFENCE instruction (introduced to the IA-32 architecture in the Pentium III
> processor) and the LFENCE and MFENCE instructions (introduced in the Pentium 4 and
> Intel Xeon processors) provide memory ordering and serialization capability for specific
> types of memory operations.
> • The memory type range registers (MTRRs) can be used to strengthen or weaken memory
> ordering for specific area of physical memory (see Section 10.11., “Memory Type Range
> Registers (MTRRs)”). MTRRs are available only in the Pentium 4, Intel Xeon, and P6
> family processors.
> • The page attribute table (PAT) can be used to strengthen memory ordering for a specific
> page or group of pages (see Section 10.12., “Page Attribute Table (PAT)”). The PAT is
> available only in the Pentium 4, Intel Xeon, and Pentium III processors.
> These mechanisms can be used as follows.
> Memory mapped devices and other I/O devices on the bus are often sensitive to the order of
> writes to their I/O buffers. I/O instructions can be used to (the IN and OUT instructions) impose
> strong write ordering on such accesses as follows. Prior to executing an I/O instruction, the
> processor waits for all previous instructions in the program to complete and for all buffered
> writes to drain to memory. Only instruction fetch and page tables walks can pass I/O instructions.
> Execution of subsequent instructions do not begin until the processor determines that the
> I/O instruction has been completed.
> Synchronization mechanisms in multiple-processor systems may depend upon a strong
> memory-ordering model....

Guys, do not mistake everything. "memory" clobbering constraint has nothing in common with CPU memory barrier.
"memory" constraint tells GCC that it can't cache expressions from memory after crossing the command. That is, normally,
 GCC could reuse value evaluated earler unless it is marked with "volatile" but now it can't do it any more and must re-
read it from memory once again.
Memory barrier for processor is one of instructions (as I mentioned in previous post) that forces the proecssor to wait 
until all pending writes to memory complete and does not allow it to start pre-fetching values for memory access 
instructions that are scheduled for execution after the barrier. That is, the memory barrier ensures that everything 
that has been scheduled for writing to memory if flushed to memory (or to processor cache to extent sufficient to be 
recognized by other processors in the system) before crossing the barrier and none of the next reads start until 
crossing the barrier. And no assembler constraints affect this - just some selected assembler instructions.

> The asm for it does have a "memory" constraint, but I haven't had a chance to 
> check if that causes the compiler to produce a proper SMP memory barrier on 
> all platforms.  (Things are a little busy around here right now ;-)  Even so, 
> I'm inclined to leave things as they are until 6.4.1 is out the door.
> 
> -----Original Message-----
> From: Attilla Danko [mailto:community-noreply@qnx.com]
> Sent: Thu 4/9/2009 6:07 PM
> To: ostech-core_os
> Subject: Re: A bug in pthread_mutex_unlock()
>  
> I don't belive __mutex_smp_xchg() contains it's own  memory barrier. All ofthe
>  other references to it call some form of memory barrier first. 
> 
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post26653
> 
>