Re: Compile Barrier

• Previous message: Peter Duniho: "Re: reverse dns lookup - pls help"
• In reply to: Vladimir_petter: "Re: Compile Barrier"
• Messages sorted by: [ date ] [ thread ]

Date: Wed, 19 Jan 2005 01:24:55 +0530

Thanks a lot Vladimir, for your detailed explanation. It did make a lot
of sense to me.

Regards,
Gary.

Vladimir_petter wrote:
> Hello Gary,
>
> There are several aspects of this issue:
>
> Barrier addressing issue with instructions reordering (pipelining feature on
> the modern processors). Modern processors (and compilers) for the sake of
> speed may reorder instructions. So a barrier is a mechanism for a programmer
> to disable certain instruction reordering.
>
> Some modern processors use relaxed (not sequential) memory model. That means
> result of assembly instructions may be visible on the main memory in an
> order different from the order how they were executed on a processors. In
> that case barrier is a mechanism to provide a guarantee on the data
> visibility on the main memory.
>
> In the C++ standard there is no any notion of threads or synchronization so
> optimizer may do some instruction reordering that may affect program's
> correctness. To address this issue compiler writes recognize some functions
> (that may be intrinsic anyways) as a barrier instruction for optimizer.
>
> In the following sample you want to guarantee
> - b will be read after lock is acquired
> - a will be written to the main memory before the lock is released
>
> lock()
> if(b) {
> ++a
> }
> unlock();
>
> The risks here is that optimizer (or processor due to pipelining or relaxed
> memory model) may move reading of b before the lock. For the compiler
> solution would be to make it recognize lock as a fence for the optimizer, or
> use an existing compiler intrinsic inside the lock implementation. For the
> processor solution would be use a fence instruction inside the lock
> implementation. In most cases the function that compiler recognizes as a
> barrier is a barrier instruction for a processor.
> Same speculations are true for reordering ++a and unlock.
>
> For some processors that do not rearrange instructions and use sequential
> consistency model no special instructions required in that case the
> compiler's intrinsic would be effectively a nop, but still will be
> recognized by a compiled as a fence for optimizer.
>
> As an example see:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/k105_972df62d-6449-40d7-9bfa-0c420cf8f106.xml.asp
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/k105_726784db-9a2c-4b1a-8e73-9edd8238649e.xml.asp
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/memorybarrier.asp
>
> Regards,
> Vladimir.
>
> "Gary" <debugger@newsgroup.nospam> wrote in message
> news:WQ7Hd.22$p85.43@news.oracle.com...
>
>>Any thoughts on What do we mean by compiler barrier ? Is it something to
>>do with concurrent processing on multi CPU boxes ?
>>Do we achieve the concurrency by putting in a func call in between the
>>code wherein the func is like a no-op ..... like :
>>
>>void noop(void)
>>{
>>}
>>
>>or may be blank hash_define like ....
>>#define noop () <no_text>
>>
>>
>>Would appreciate some light on this if anybody has some ideas.
>>
>>Thanks,
>>Gary.
>
>
>

• Previous message: Peter Duniho: "Re: reverse dns lookup - pls help"
• In reply to: Vladimir_petter: "Re: Compile Barrier"
• Messages sorted by: [ date ] [ thread ]