Re: plea for review
- From: Tim Janik <timj gtk org>
- To: Sebastian Wilhelmi <wilhelmi ira uka de>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: plea for review
- Date: Tue, 6 Feb 2001 20:38:09 +0100 (CET)
On Tue, 6 Feb 2001, Sebastian Wilhelmi wrote:
> Hi Tim,
>
> > i went over gtype.c and inserted the required locks to make it thread safe.
> > however, the code is far from simple, there are more than 100 lock/unlock
> > calls now.
> > that's why i'd like to have it reviewed by as many eyes as possible, intrinsic
> > knowledge of the type system isn't strictly neccessary to catch basic locking
> > issues, so please take the time and have a look (especially sebastian).
>
> I looked over it (the CVS-version of gtype.c) for the last 3 hours and didn't
> find any pitfalls, apart from being a bit unhappy about calling external code
> in the middle of write updates. But I agree, bad consequences should be quite
> improbable, though not impossible. The only thing that should be changed is to
> remove the type_init_lock, as it doesn't seem to have any use here. Patch
> attached.
tricky case:
thread1: g_type_init() // acquires write lock
thread2: g_type_init() // wait, lock held by thread1
thread1: do basic field setups
thread1: release write lock
thread2: acquire wirte lock
thread2: find out g_type_init() has already been caled, return
thread1: do some more type initialization, but not all yet
thread2: call some function that relies on the type system being
fully initialized (which thread1 hasn't finished yet) => boom
there're two scenarios:
1) people call g_type_init() and then start individual threads - fine
2) people start several threads that call g_type_init() on their own
for (2), the above "tricky" scenario could occour, so the intend of that
extra g_type_init lock is to block other g_type_init() callers until
the first one completed intialization.
>
> Bye,
> Sebastian
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]