This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: robust pthread_mutex_t in shared memory
- From: Michal Vaško <mvasko at cesnet dot cz>
- To: "Florian Weimer" <fweimer at redhat dot com>
- Cc: libc-help at sourceware dot org
- Date: Mon, 15 Apr 2019 12:06:37 +0200
- Subject: Re: robust pthread_mutex_t in shared memory
Hi Florian,
sorry for not giving details but I do not know which are relevant and which not. Yes, munmap() followed by mmap() resulting in different address but there is no real backing file, the file descriptor passed to mmap() is obtained from shm_open().
Regards,
Michal
On Monday, April 15, 2019 11:58 CEST, Florian Weimer <fweimer@redhat.com> wrote:
> * Michal Vaško:
>
> > I have a use-case of process-shared mutexes in shared memory. The
> > memory is even remapped at times but never while the lock is held. I
> > have encountered some strange behavior and while debugging I wrote a
> > fairly simple program that I would like to ask for help with. I would
> > also appreciate if someone could tell me (or point me to where it is
> > documented) what are the restrictions when using mutexes this way such
> > as whether the memory can be remapped while a lock in it is held
> > (probably not possible for robust mutexes, what about the default
> > ones?) or similar ones.
>
> What do you mean by “remapped”? munmap followed by another mmap from
> the backing file, possibly resulting in a different address?
>
> Thanks,
> Florian