This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: dlopen handles and multiple threads
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Thu, 3 Jul 2014 14:10:13 +0000
- Subject: RE: dlopen handles and multiple threads
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B0235320E5E2BD at LEMAIL01 dot le dot imgtec dot org> <20140703140052 dot GZ179 at brightrain dot aerifal dot cx>
Rich Felker <dalias@libc.org> writes:
> On Thu, Jul 03, 2014 at 10:22:13AM +0000, Matthew Fortune wrote:
> > Hi all,
> >
> > Can anyone tell me with confidence whether either of the following
> > scenarios are valid relating to sharing code between threads:
> >
> > [...]
> > Thread 1 notifies thread 2 that the handle is available (by whatever
> mechanism)
>
> This step is the only one which is suspicious. I'm not clear what "by
> whatever mechanism" means, but if the mechanism is anything other than
> one of the standard functions which synchronizes memory (e.g.
> pthread_mutex_lock/unlock or sem_wait/post) or an atomic operation
> which does so, it's not valid.
Indeed. I just didn't want to enumerate the valid ways to achieve it.
> As long as this is done correctly, both scenarios are fully valid, and
> in fact you would expect them to occur in ordinary usage -- for
> example, consider a gui application where the gui is running in a
> separate thread and another thread loads a module for a feature and
> registers interface elements for it, where the gui will later callback
> indirectly into the code from the loaded module.
Thanks Rich. I'll plan to account for these kind of use cases with my work.
Matthew