grand-central-dispatch | 易学教程

Sync dispatch on current queue

阅读更多关于 Sync dispatch on current queue

I know you might find this an odd question, but I'm just learning GCD and I want to fully understand all its aspects. So here it is: Is there ever any reason to dispatch a task SYNC on the CURRENT QUEUE? For example: dispatch_queue_t concurrentQueue = dispatch_get_global_queue(...); dispatch_async(concurrentQueue, ^{ //this is work task 0 //first do something here, then suddenly: dispatch_sync(concurrentQueue, ^{ //work task 1 }); //continue work task 0 }); I understand one thing: if instead of concurrentQueue I use a serial queue, then I get a deadlock on that serial queue, because work task

requestAccessForMediaType doesn't ask for permission

阅读更多关于 requestAccessForMediaType doesn't ask for permission

问题 I noticed that my app doesn't request permission to use the camera. After some experimentation I figured out that the piece of code used to check permission takes a very long time to complete. So I thought of letting that part of my viewdidload run on a serial queue (sync). Forcing the rest to wait for the auth process to complete before starting the next line. But that doesn't really work. The lines start in order, but still don't finish in order. The strange thing is if I just call for the

What is the correct way to release a GCD dispatch queue property?

阅读更多关于 What is the correct way to release a GCD dispatch queue property?

I'm using a dispatch_queue which is accessed through a property of its owner, like this: @property (nonatomic, assign) dispatch_queue_t queue; Note the assign keyword. The queue is used throughout the objects life and thus owned by the object. I release the queue when the owning object is deallocated: -(void)dealloc { dispatch_release(self.queue); self.queue = nil; } How do I properly release this? Would using retain/release work? What happens if there is stuff pending/running on the queue while calling release? Stephen Poletto The following is stolen from the developer documentation: Dispatch

When to use NSEnumerationConcurrent

阅读更多关于 When to use NSEnumerationConcurrent

Every now and then, I notice that I'm using a block to iterate over a collection without writing to any shared data or causing any side effects. I consider adding in an NSEnumerationConcurrent option, then decide against it as I don't really understand when it's worth using. So I've got a specific question, and a more general one. First question: Here's a maybe slightly contrived example of using a block to do something trivial concurrently: CGFloat GetAverageHeight(NSArray* people) { NSUInteger count = [people count]; CGFloat* heights = malloc(sizeof(CGFloat) * count); [people

dispatch_after equivalent in NSOperationQueue

阅读更多关于 dispatch_after equivalent in NSOperationQueue

I'm moving my code from regular GCD to NSOperationQueue because I need some of the functionality. A lot of my code relies on dispatch_after in order to work properly. Is there a way to do something similar with an NSOperation ? This is some of my code that needs to be converted to NSOperation . If you could provide an example of converting it using this code, that would be great. dispatch_queue_t queue = dispatch_queue_create("com.cue.MainFade", NULL); dispatch_time_t mainPopTime = dispatch_time(DISPATCH_TIME_NOW, (int64_t)(timeRun * NSEC_PER_SEC)); dispatch_after(mainPopTime, queue, ^(void){

Delaying Code Execution on OSX 10.10

阅读更多关于 Delaying Code Execution on OSX 10.10

I've encountered a very strange issue that affects my code running only on OSX 10.10 systems. I've seen this anomaly occur on over 25 OSX 10.10 systems running my code, whereas the exact same code did not exhibit this behavior before upgrading (10.7). Furthermore, this issue is not 100% reproducible in that it occurs randomly ~0-5% of the time. While testing the code, nothing else critical or CPU exhaustive is occurring on the machine. Even if something else was happening, the very fact that the delays I'm experiencing are soooo ridiculously long make that conclusion seem suspicious. Anyhow,

is this GCD implemented getter setter thread safe and work better than @synchronized? objc

阅读更多关于 is this GCD implemented getter setter thread safe and work better than @synchronized? objc

@interface ViewController () @property (nonatomic, strong) NSString *someString; @end @implementation ViewController @synthesize someString = _someString; - (NSString *)someString { __block NSString *tmp; dispatch_sync(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ tmp = _someString; }); return tmp; } - (void)setSomeString:(NSString *)someString { __block NSString *tmp; dispatch_barrier_sync(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ tmp = someString; }); _someString = tmp; } @end some said it's better than @synchronized way because all the locking is

Is it safe to schedule and invalidate NSTimers on a GCD serial queue?

阅读更多关于 Is it safe to schedule and invalidate NSTimers on a GCD serial queue?

问题 What's the right way to do this? The NSTimer documentation says this: Special Considerations You must send this message from the thread on which the timer was installed. If you send this message from another thread, the input source associated with the timer may not be removed from its run loop, which could prevent the thread from exiting properly. Since GCD doesn't assure you that a serial queue will always run blocks on the same thread, what's the right way to ensure that you schedule and

Synchronize Properties in Swift 3 using GCD

阅读更多关于 Synchronize Properties in Swift 3 using GCD

问题 I watched this years WWDC GCD talk lately and I think there is a code snippet something is wrong with. It is about making a property thread-safe using DispatchQueues . class MyObject { private var internalState: Int private let internalQueue: DispatchQueue // Serial or Concurrent? var state: Int { get { return internalQueue.sync { internalState } } set (newState) { internalQueue.sync { internalState = newState } } } } They use a DispatchQueue to lock a property. But i think this snippet is

Should I avoid creating JSContexts in global queues?

阅读更多关于 Should I avoid creating JSContexts in global queues?

I've just had a crash log from a customer's device, and it's crashing here: dispatch_async(dispatch_get_global_queue(0, 0), ^{ JSContext *javaScriptContext = [[JSContext alloc] init]; Here's the crash log: Thread 11 Crashed: 0 JavaScriptCore 0x31009cd6 WTFCrash + 54 1 JavaScriptCore 0x30e0edf6 WTF::OSAllocator::reserveAndCommit(unsigned long, WTF::OSAllocator::Usage, bool, bool, bool) + 166 2 JavaScriptCore 0x30e0ed2a WTF::OSAllocator::reserveUncommitted(unsigned long, WTF::OSAllocator::Usage, bool, bool, bool) + 14 3 JavaScriptCore 0x30e14736 JSC::JSStack::JSStack(JSC::VM&, unsigned long) +