[bug #24784] Thread safety issue with NSCalendarDate...

[David Ayers]

Follow-up Comment #8, bug #24784 (project gnustep):

Thanks!

I've looked at the patch and it looks correct but does seem rather
complicated but I believe I understand the dilemma.

We want to avoid adding extra checks (like CLS_ISINITIALIZED which would have
to be adapted anyways) the hot path.

We are constrained in the class structure layout due to binary compatibility
(or we would add a preliminary dtable there to avoid the external linked list,
and have message dispatch also check there under the recursive lock on the
cold path). 

But I'm wondering if we could use the dtable of the meta class during
initialization as a fallback for the cold path under the mutex... i.e.:

if
a) the classes dtable is not set yet
b) the dtable of the meta class is set

assume we are currently initializing so lets take the mutex to insure we are
thread that's initializing (double checking once we have the lock to see if
some other thread was just finishing up)

If we got the lock and the dtable of the meta class is still set, we can
assume this is the thread sending a message lookup during +initialize.  We use
the meta classes dtable for message lookup to finish processing +initialize.

I still need to verify that the dtable of the meta class isn't used for
anything else.  I'm also haven't convinced myself that this can't produce a
deadlock yet.  But it would be great if we could avoid the linked list and all
the extra helper functions.

I was hoping to come up with a proof-of-concept during the holidays but that
didn't work out so I decided to post the idea for now.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?24784>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/