gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thread question


From: Richard Frith-Macdonald
Subject: Re: Thread question
Date: Sat, 5 Mar 2011 17:06:12 +0000

On 4 Mar 2011, at 18:24, Banlu Kemiyatorn wrote:

> On Sat, Mar 5, 2011 at 1:03 AM, Richard Frith-Macdonald
> <address@hidden> wrote:
> 
> Thanks! I switched to GNUstep objc runtime now and the problem is
> gone. Thank you Richard and David.
> 
>> I suspect that what you have run into here is a bug in the gnu Objective-C 
>> runtime.
>> 
>> You have two threads started and immediately calling NSLog, which in turn 
>> immediately tries to access the user defaults system.
>> The user defaults system is protected by a lock 'classLock' created in its 
>> +initialize method, which is run automatically by the runtime.
>> The +initialize method is supposed to run in a thread-safe manner *before* 
>> any other method in the class can run ... so this should mean that 
>> classLock, created in +initialize, can safely be used later.
>> 
>> What I think is happening is that one thread calls the +standarduserDefault 
>> method, and the runtime calls +initialize, then before +initialize has 
>> completed, the second thread calls +standardUserDefaults (and the runtime 
>> incorrectly lets it), which tries to lock classLock before it has been 
>> created.  This will send a _lock method to a nil object, which does nothing. 
>>  The thread then creates the shared user defaults object and tries to unlock 
>> classLock, but by this time the first thread has created the lock, so an 
>> -unlock message is sent to classLock when in has not been locked.
>> 
>> This bug only rarely manifests, since it depends on a race condition when a 
>> class is initialized, and in most non-trivial programs, most important 
>> classes are used before any threads are started.  You could check to see if 
>> this is your problem by calling any NSUserDefaults method before starting 
>> the threads...  if it is, doing that will prevent the exception from 
>> occurring.
>> 
>> Unless it's been fixed, this is probably the biggest outstanding bug in the 
>> gnu runtime.

I added a configure-time check in gnustep-base to detect objc runtime libraries 
which don't support +initialise properly and warn about them.
I also added a run-time alert to be printed if a program becomes multithreaded 
and configure had detected that the runtime library was not thread safe.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]