undefined | Better HN

0 pointshedgehog14y ago0 comments

You're right in general but starting in iOS4:

"Drawing to a graphics context in UIKit is now thread-safe." http://developer.apple.com/library/ios/#releasenotes/General...

Some things won't work (notably UIWebView which also gets used in UITextView) but you actually can build a view in a NSOperation.

0 comments

beatle14y ago

dvmLockMutex(&gDvm.heapWorkerLock);

//BUG: If a GC happens in here or in the new thread while we hold the lock,

// the GC will deadlock when trying to acquire heapWorkerLock.

if (!dvmCreateInternalThread(&gDvm.heapWorkerHandle, "HeapWorker", heapWorkerThreadStart, NULL))

{ dvmUnlockMutex(&gDvm.heapWorkerLock);

        return false;

}
// Block until all pending heap worker work has finished.
void dvmWaitForHeapWorkerIdle() { int cc;
assert(gDvm.heapWorkerReady); dvmChangeStatus(NULL, THREAD_VMWAIT); dvmLockMutex(&gDvm.heapWorkerLock); /* Wake up the heap worker and wait for it to finish. */ //TODO(http://b/issue?id=699704): This will deadlock if // called from finalize(), enqueue(), or clear(). We // need to detect when this is called from the HeapWorker // context and just give up. dvmSignalHeapWorker(false); cc = pthread_cond_wait(&gDvm.heapWorkerIdleCond, &gDvm.heapWorkerLock); assert(cc == 0);

    dvmUnlockMutex(&gDvm.heapWorkerLock);

    dvmChangeStatus(NULL, THREAD_RUNNING);

}

blinkingled14y ago
With this type of thread management they're required to trap into the kernel to acquire a mutex. There are obviously severe performance issues with this which partly explains some of the blocking and performance issues in Androids garbage collector
Android runs on Linux. Linux uses Futexes (Fast Userspace Mutexes) for locking abstractions like semaphores and mutexes. From Wikipedia -
"A futex consists of a kernelspace wait queue that is attached to an aligned integer in userspace. Multiple processes or threads operate on the integer entirely in user space (using atomic operations to avoid interfering with one another), and only resort to relatively expensive system calls to request operations on the wait queue (for example to wake up waiting processes, or to put the current process on the wait queue). A properly programmed futex-based lock will not use system calls except when the lock is contended; since most operations do not require arbitration between processes, this will not happen in most cases."
beatle14y ago
Android's garbage collection is handled by Dalvik.
1 more reply

j / k navigate · click thread line to collapse

0 comments

beatle14y ago

Here's another problem with HeapWorker.c (The android code that does garbage collection, etc.). This is just poor programming imo. Android's thread management is stuck in the 90s. With this type of thread management they're required to trap into the kernel to acquire a mutex. There are obviously severe performance issues with this which partly explains some of the blocking and performance issues in Androids garbage collector, not to mention the possibility of bugs and deadlocks. (see actual android code below). iOS has been migrating away from threads and using dispatch and operation queues (Grand Central Dispatch) instead, which eliminates most of the blocking and possibilities for deadlocks. sometimes performance issues are just results of poor programming.
dvmLockMutex(&gDvm.heapWorkerLock);
//BUG: If a GC happens in here or in the new thread while we hold the lock,
// the GC will deadlock when trying to acquire heapWorkerLock.
if (!dvmCreateInternalThread(&gDvm.heapWorkerHandle, "HeapWorker", heapWorkerThreadStart, NULL))
{ dvmUnlockMutex(&gDvm.heapWorkerLock);
return false;
}
// Block until all pending heap worker work has finished.
void dvmWaitForHeapWorkerIdle() { int cc;
assert(gDvm.heapWorkerReady); dvmChangeStatus(NULL, THREAD_VMWAIT); dvmLockMutex(&gDvm.heapWorkerLock); /* Wake up the heap worker and wait for it to finish. */ //TODO(http://b/issue?id=699704): This will deadlock if // called from finalize(), enqueue(), or clear(). We // need to detect when this is called from the HeapWorker // context and just give up. dvmSignalHeapWorker(false); cc = pthread_cond_wait(&gDvm.heapWorkerIdleCond, &gDvm.heapWorkerLock); assert(cc == 0);

dvmUnlockMutex(&gDvm.heapWorkerLock); dvmChangeStatus(NULL, THREAD_RUNNING);
}

j / k navigate · click thread line to collapse