| Author |
Re: IBM p690 Power4 Shared Memory
|
|
| Chris Thomasson 2007-06-19, 4:16 am |
| <techinfo7@gmail.com> wrote in message
news:1182205154.559290.258230@q19g2000prn.googlegroups.com...
[...]
> Does anyone know how can I generate the functions to perform sync,
> lsync, eieio, etc. function calls mentioned in the reference paper on
> SLES using g++? Does anyone have further information on this topic?
You can create your own using the GCC Assembler:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02374.html
| |
| Jeremy Linton 2007-06-19, 7:09 pm |
|
Chris Thomasson wrote:
> <techinfo7@gmail.com> wrote in message
> news:1182205154.559290.258230@q19g2000prn.googlegroups.com...
> [...]
>
> You can create your own using the GCC Assembler:
>
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02374.html
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")
| |
| Jeremy Linton 2007-06-19, 7:09 pm |
|
Jeremy Linton wrote:
> #define SyncMemory() __asm__("lwsync\n"::"memory")
Whoops that should be:
#define SyncMemory() __asm__("lwsync\n":::"memory")
| |
| Chris Thomasson 2007-06-19, 10:07 pm |
| "Jeremy Linton" <replytothelist@nospam.com> wrote in message
news:467839ac$0$24723$4c368faf@roadrunne
r.com...
>
>
> 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.
Okay. Yeah, I assume you would sync after the atomic-op that acquires the
lock, and an lwsync before the atomic-op that releases the lock...
I am not sure if:
lwsync ==
the SPARC version:
membar #LoadStore | #StoreStore
However, I do believe that sync is ==
membar #StoreLoad | #StoreStore
[...]
Are you sure that lwsync is a release barrier strong enough to release the
mutex?
|
|
|
|