Unix Programming - Re: IBM p690 Power4 Shared Memory

Author

Re: IBM p690 Power4 Shared Memory

techinfo7@gmail.com

2007-06-21, 10:05 pm

On Jun 19, 1:16 pm, Jeremy Linton <replytothel...@nospam.com> wrote:
> Chris Thomasson wrote:
> Those are just for individual memory locations. I assume the problem is
> that the application isn't explicitly flushing changes because the
> locking mechanism isn't flushing the changes itself. I'm guessing he
> needs a lwsync before the lock drop. This will guarantee the data
> written before the lock drop is actually synced to memory so the next
> lock owner reads the correct data.
>
> I thought pthread_mutex_xx did the right thing. I'm guessing that the
> original author isn't using pthread_mutex's. So he probably needs a
> little piece of code like:
>
> #define SyncMemory() __asm__("lwsync\n"::"memory")

Correct, we don't use any locking mechanisms on shared memory (shmget,
shmat, etc.) for performance reasons. With our software, it is very
important that the write order is preserved on data written to shared
memory. From what I understand, using the eieio will enforce the
ordering of i/o to memory.

I am going to try these suggestions today. I will let you know how
things turn out.

Thanks for the advice,
Maria

Jeremy Linton

2007-06-21, 10:05 pm

techinfo7@gmail.com wrote:
> On Jun 19, 1:16 pm, Jeremy Linton <replytothel...@nospam.com> wrote:
[color=darkred]
> Correct, we don't use any locking mechanisms on shared memory (shmget,
> shmat, etc.) for performance reasons. With our software, it is very
> important that the write order is preserved on data written to shared
> memory. From what I understand, using the eieio will enforce the
> ordering of i/o to memory.
My understanding is that eieio is a super scalar pipeline control, more
than a memory barrier. You might also look at this link
http://www.ibm.com/developerworks/e...es/powerpc.html which
explicitly states:

"However, eieio has no effect on the order in which two accesses are
performed if one access is to device memory and the other is to system
memory. Also, eieio has no effect in ordering loads to system memory,
and it's not recommended for ordering stores to system memory. As a
final note, eieio is not cumulative for device memory accesses. This is
in contrast to the sync instruction, as described below."

Your original link also says "Creates a memory barrier that provides the
same ordering function as the sync instruction except that ordering
applies only to accesses to I/O memory."

So unless your memory is marked uncached, then the eieio instruction
probably doesn't do what you want.

Sponsored Links