This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: dlopen handles and multiple threads
- From: Rich Felker <dalias at libc dot org>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Thu, 3 Jul 2014 10:00:52 -0400
- Subject: Re: dlopen handles and multiple threads
- Authentication-results: sourceware.org; auth=none
- References: <6D39441BF12EF246A7ABCE6654B0235320E5E2BD at LEMAIL01 dot le dot imgtec dot org>
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.
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.
Rich