在Grand Central Dispatch中使用dispatch_sync

任何人都可以用真正清楚的用例来解释GCDdispatch_sync的用途是什么? 我不明白在哪里,为什么我不得不使用这个。

谢谢!

当你想要执行一个块并等待结果时使用它。

其中一个例子就是您使用调度队列而不是同步锁的模式。 例如,假设你有一个共享的NSMutableArray a ,访问由调度队列q调用。 后台线程可能会附加到数组(asynchronous),而您的前台线程closures(同步)第一个项目:

 NSMutableArray *a = [[NSMutableArray alloc] init]; // All access to `a` is via this dispatch queue! dispatch_queue_t q = dispatch_queue_create("com.foo.samplequeue", NULL); dispatch_async(q, ^{ [a addObject:something]; }); // append to array, non-blocking __block Something *first = nil; // "__block" to make results from block available dispatch_sync(q, ^{ // note that these 3 statements... if ([a count] > 0) { // ...are all executed together... first = [a objectAtIndex:0]; // ...as part of a single block... [a removeObjectAtIndex:0]; // ...to ensure consistent results } }); 

先了解它的兄弟dispatch_async

 //Do something dispatch_async(queue, ^{ //Do something else }); //Do More Stuff 

你使用dispatch_async来创build一个新的线程。 当你这样做,当前线程不会停止。 这意味着/ / //Do More Stuff可能会执行//Do something else之前//Do something else完成

如果你想让当前线程停止,会发生什么?

你根本不用派遣。 只要正常写代码

 //Do something //Do something else //Do More Stuff 

现在,假设你想在一个不同的线程上做些事情,然后等待,并确保连续完成这些事情。

这样做有很多理由。 例如,UI更新在主线程上完成。

这就是你使用dispatch_sync的地方

 //Do something dispatch_sync(queue, ^{ //Do something else }); //Do More Stuff 

在这里,你得到/ / //Do something //Do something else和/ / //Do More stuff连续完成,即使//Do something else是在不同的线程完成。

通常情况下,当人们使用不同的线程时,整个目的就是让一些东西不用等待就可以执行。 假设你想要下载大量的数据,但你想保持UI平滑。

因此,dispatch_sync很less使用。 但它在那里。 我个人从来没有使用过。 为什么不要求使用dispatch_sync的示例代码或项目。

dispatch_sync在语义上等同于传统的互斥锁。

 dispatch_sync(queue, ^{ //access shared resource }); 

和…一样

 pthread_mutex_lock(&lock); //access shared resource pthread_mutex_unlock(&lock); 

如果你想要一些实际使用的样品看看我的这个问题:

我如何解决这个偶然发生的僵局?

我通过确保在主线程上创build主要的managedObjectContext来解决这个问题。 这个过程非常快,我不介意等待。 不等待意味着我将不得不面对很多问题。

我需要dispatch_sync,因为一些代码需要在主线程上完成,这是与正在执行代码的线程不同的线程。

所以基本上如果你想要的代码1.像往常一样继续。 你不想担心比赛条件。 在继续之前,您要确保代码已经完成。 2.在不同的线程上完成

使用dispatch_sync。

如果违反了1,请使用dispatch_async。 如果违反了2,就像往常一样写代码。

到目前为止,我只做了一次,即在主线程上需要做些什么的时候。

所以这是代码:

 +(NSManagedObjectContext *)managedObjectContext { NSThread *thread = [NSThread currentThread]; //BadgerNewAppDelegate *delegate = [BNUtilitiesQuick appDelegate]; //NSManagedObjectContext *moc = delegate.managedObjectContext; if ([thread isMainThread]) { //NSManagedObjectContext *moc = [self managedObjectContextMainThread]; return [self managedObjectContextMainThread]; } else{ dispatch_sync(dispatch_get_main_queue(),^{ [self managedObjectContextMainThread];//Access it once to make sure it's there }); } // a key to cache the context for the given thread NSMutableDictionary *managedObjectContexts =[self thread].managedObjectContexts; @synchronized(self) { if ([managedObjectContexts objectForKey:[self threadKey]] == nil ) { NSManagedObjectContext *threadContext = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateQueueConcurrencyType]; threadContext.parentContext = [self managedObjectContextMainThread]; //threadContext.persistentStoreCoordinator= [self persistentStoreCoordinator]; //moc.persistentStoreCoordinator;// [moc persistentStoreCoordinator]; threadContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy; [managedObjectContexts setObject:threadContext forKey:[self threadKey]]; } } return [managedObjectContexts objectForKey:[self threadKey]]; } 

大卫Gelhar留下没有说他的例子将工作,只是因为他悄悄地创build串行队列(dispatch_queue_create等于DISPATCH_QUEUE_SERIAL传递NULL)。

如果你想创build并发队列(获得所有的multithreading能力),他的代码将导致崩溃,因为NSArray突变(addObject :)在突变期间(removeObjectAtIndex :)或甚至不良访问(NSArray范围超出界限)。 在这种情况下,我们应该使用barrier来确保在两个块运行时独占访问NSArray。 它不仅在运行时将所有其他写入操作排除在NSArray之外,还排除了所有其他读取操作,从而使修改变得安全。

并发队列示例应如下所示:

 NSMutableArray *a = [[NSMutableArray alloc] init]; // All access to `a` is via this concurrent dispatch queue! dispatch_queue_t q = dispatch_queue_create("com.foo.samplequeue", DISPATCH_QUEUE_CONCURRENT); // append to array concurrently but safely and don't wait for block completion dispatch_barrier_async(q, ^{ [a addObject:something]; }); __block Something *first = nil; // pop 'Something first' from array concurrently and safely but wait for block completion... dispatch_barrier_sync(q, ^{ if ([a count] > 0) { first = [a objectAtIndex:0]; [a removeObjectAtIndex:0]; } }); // ... then here you get your 'first = [a objectAtIndex:0];' due to synchronised dispatch. // If you use async instead of sync here, then first will be nil. 

dispatch_sync主要用在dispatch_async块内对主线程执行一些操作(如更新ui)。

 dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ //Update UI in main thread dispatch_sync(dispatch_get_main_queue(), ^{ self.view.backgroundColor = color; }); }); 

这是一个中途现实的例子。 你有2000个zip文件,你想并行分析。 但是,zip库不是线程安全的。 因此,所有涉及zip库的工作都会进入unzipQueue队列。 (这个例子是在Ruby中,但是所有的调用都直接映射到C库。“apply”,例如maps到dispatch_apply(3) )

 #!/usr/bin/env macruby -w require 'rubygems' require 'zip/zipfilesystem' @unzipQueue = Dispatch::Queue.new('ch.unibe.niko.unzipQueue') def extractFile(n) @unzipQueue.sync do Zip::ZipFile.open("Quelltext.zip") { |zipfile| sourceCode = zipfile.file.read("graph.php") } end end Dispatch::Queue.concurrent.apply(2000) do |i| puts i if i % 200 == 0 extractFile(i) end 

在asynchronous调度中,我使用了调度同步来将UI更改通知给主线程。

我的asynchronous块阻挡了一点,我知道主线程知道UI的变化,并会采取行动。 通常在需要一些CPU时间的处理代码块中使用这个,但是我仍然想要在该块内动作UI更改。 在asynchronous块中操作UI更改是无用的,因为UI相信在主线程上运行。 同时将它们作为辅助asynchronous块或自我委托来执行,导致用户界面仅在几秒钟之后才看到它们,并且看起来很迟缓。

示例块:

 dispatch_queue_t myQueue = dispatch_queue_create("my.dispatch.q", 0); dispatch_async(myQueue, ^{ // Do some nasty CPU intensive processing, load file whatever if (somecondition in the nasty CPU processing stuff) { // Do stuff dispatch_sync(dispatch_get_main_queue(),^{/* Do Stuff that affects UI Here */}); } });