RE: More PTHREAD_PROCESS_SHARED(Storing pointers into shared memory?)

This is clearly a bug, seems like we have to nail the NGPT shared area
to a 
known virtual address that all processes using shared mutexes would use.
It 
is unfortunate but necessary to add restrictions like this with the
current
implementation, we should investigate other ways to implement this.

I just modified pth_sync.c in the call to mmap to use a start address of
a 
constant 0x48000000, this should keep it at the same virtual address for
all processes that use the ngpt runtime. Is there a better place to put
this to keep it out of the way of other mmaps, or just to place it
better for efficiency? Also, the man page says that 'start' is a hint
only, that's scary for a solution like this. 

But this may help folks who are stuck on this to make progress. We could
for the short term do this and make it a configuration time tuneable.

Any thoughts? 
 
Dave Howell

-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Tuesday, January 07, 2003 3:34 PM
To: [email protected]
Subject: Re: [pthreads-devel] More PTHREAD_PROCESS_SHARED(Storing
pointers into shared memory?)



I have written code that demonstrates the problem.  This scenario
involves two programs(proga, progb) executing the same code that
manipulates some shared data protected with a PTHREAD_PROCESS_SHARED
mutex. Both programs use the same initialization code to map its shared
memory and, if necessary, initialize the mutex.  The only difference
between the two is that progb has another library linked in (libbreak).
This library doesn't do anything but allocate some memory, but takes up
address space causing the internal NGPT shared memory to be mapped at a
different address than proga.  The source to everything is in the
attached tarball.

After initialization, each program acquires the mutex, prints out the
shared data, then updates it to be the programs name (argv[0]).  Before
each step it asks the user to press enter (this way you can get the
other program started).

If you run two instances of proga, or two instances of progb, everything
works as expected.  Running proga with progb causes the locks not to
work (seemingly ignored).

I found it useful to add this code to the bottom of
pth_initialize_shared():

    fprintf(stderr, "NGPT: shared area pointer: %p\n", pth_shared_area);

You can see then, that the memory is mapped to a different address in
progb then proga.

to test:
   untar ngptproblem.tar.gz
   ./configure --with-ngptdir=/your/ngpt/path
   make
   ./proga
   (on another tty)
   ./progb (or proga if you want to see it work)

   The first <enter> locks the mutex, prints out the data, then updates
it.  The second <enter> unlocks the mutex.  So hit enter on proga, then
hit enter on progb.  The lock wont be honored and the critical section
executes(because the pointer in the shared mutex is wrong from progb's
perspective).


Here is the output from proga:

NGPT: shared area pointer: 0x40195000
internal mutex pointer: 0x40198200
press a key to obtain the lock and update data

locking mutex...
locked
shared data is ''
press a key to unlock the mutex

unlocking mutex...
unlocked

And here from progb:

NGPT: shared area pointer: 0x40197000
Initializing library
press a key to obtain the lock and update data

locking mutex...
locked
shared data is './proga'
press a key to unlock the mutex

unlocking mutex...
unlocked

Thanks for taking a look,
Chris McFarlen