Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with NewThread function

> It is not any different if thread is not suspended: from the point
> of view of a given thread any other thread state is unknown. On a
> single CPU system all other threads but the current are "interrupted"
> unless you explicitly use synchronization APIs. On a multi CPU system
> all other threads but the current are either "interrupted" or in
> "indeterminate" state.

You're missing the point, which is that suspend/resume functions can
deadlock threads in a way that the scheduler will not.

- Blocking on synchronization devices happens at well-known points within a
thread, such that when the shared resource is freed the thread will be
resumed by the scheduler.

- Switching out a thread potentially leaves shared resources locked and so
can block other threads, but the scheduler will at some point return control
the thread so that it finishes its work and releases the resources.

- Suspending a thread is done from outside the thread, like a context switch
such that it can leave resources locked by the thread, but without any
guarantee that thread will ever be resumed, and indeed the possibility that
the other thread that should be doing the resuming will deadlock on a
resource (the heap for instance) locked by the suspended thread.

>> In the worst case scenario, the thread was in the middle of
>> allocating a large memory block when it is suspended, possibly preventing
>> other threads (including your main thread) from allocating memory.
>
> Again, this has nothing to do with suspension. The Foo Manager is
> either thread safe or not. Malloc and friends are thread safe, so
> this is not a problem. Some other API is not thread safe, but then
> you should not call it concurrently from different threads in the
> first place and this is irrelevant to thread suspension.

Again, you miss the point. Malloc is thread safe because it correctly uses
synchronization primitives to control multiple threads accessing its data
structures. If a thread is switched out in the middle of malloc those
structures may be locked such that no other thread can call malloc, but
other attempts to call it will block and the scheduler will eventually
return control to the thread with the lock and that thread will complete the
call to malloc and release the resources. That is what it means to say
"malloc is thread safe." But if thread B suspends thread A in the middle of
malloc at such a point, then it is possible that thread B will call malloc
before trying to resume thread A and thus will deadlock, and so thread A
will never be resumed and will never release the lock, and each other thread
will in turn deadlock as soon as it tries to malloc...

>> Do you need any more examples of why suspend/resume (and kill) is BAD?
>
> One example would be enough. So far there was no one.

Well, you've been given an example. If you grok it then you will immediately
see that the argument generalizes to any "thread-safe" API.


--
Scott Ribe
email@hidden
http://www.killerbytes.com/
(303) 665-7007 voice
_______________________________________________
carbon-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/carbon-development
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: Problem with NewThread function (From: Mike Kluev <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.