On Sat, Apr 12, 2008 at 10:48:01PM +0200, Ion Gaztañaga wrote:
Ok. One process takes a lock tries to introduce new elements so increases the segment and adds more elements in a shared memory list.
Where did the memory from the new element come from?
Then unlocks the mutex. New elements allocated in the list can be introduced in the front of the list. Other processes, lock the mutex and traverse the list and crash. How can we stop all processes to notify
The one process that allocates the memory for the new list element in its shm_malloc() will do (roughly, some steps omitted from the previous post): - take the dedicated mutex - grow and map the segment in its own private address space - allocate the chunk of memory again (this must succeed now!) - asynchronously interrupt other processes - unlock the mutex - wait on the barrier - return the pointer to the application The application will not get the pointer to the new memory chunk which will be inserted into the list before all other processes have waited on the barrier, i.e. have mapped the new SHM portion of memory. Whether the element is inserted at the beginning or the end of the list is irrelevant -- no insertion will take place until the mapping has been performed by everybody.
With malloc all threads have atomically mapped that memory in their address space because they shared the address space. Once one threads successes doing it, all threads have succeed. Doing this with shared memory is a lot more difficult.
The mapping does not have to be atomic; i.e. the provided user-space primitives are sufficient to make the mapping appear atomic as long as the assumption 2) holds.