Talk:Grand Central Dispatch

Algorithm

yeah, but what's the algorithm? —Preceding unsigned comment added by 99.14.57.182 (talk • contribs) 21:59, 18 June 2008

Wtf... why ask. Nutter.. The only thing that can be asked at this stage, is how does it stop clashing, different things working on related jobs. There's a name for that sort of problem. 86.150.224.148 (talk) 20:14, 26 July 2008 (UTC)

You may be thinking of a race condition.--99.225.218.183 (talk) 19:58, 15 November 2008 (UTC)

Pure PR

The article is currently pure PR. You could just write "Grand Central is the silver bullet for multicore programming." and have content of about the same value. Does anyone know anything more about this? Probably not, since painless multicore programming is generally regarded as a still unsolved problem and a subject of the most interesting current programming language research.

It is possible that Grand Central just allows programmers to write purity annotations (search Google for more on this, especially interviews with Simon Peyton Jones). Grand Central then would do some magic to automatically deploy these to produce reasonably efficient multicore code.

In its current state, this article should be made into a paragraph of the Mac OS X v10.6 article and deleted. Subwy (talk) 20:37, 3 December 2008 (UTC)

Yeah, as it is this should basically be one sentence in the OS X 10.6 article saying something like: "Apple plans to introduce an automatic parallelization framework called 'Grand Central'." --Delirium (talk) 20:00, 16 December 2008 (UTC)

It could stand alone if more detail were added about the technology's use and implementation. The key parts are lambda functions, or blocks, and a queuing and dispatch system that is system-wide optimised. The idea is to shift the developer away from manually using threads and replace with these blocks and queues. Queuing operations are atomic, and if a local queue is created to manage a shared data resource then no locks are required, and deadlock can't occur. Such detail is interesting and would not fit well in the main Mac OS X article. I'm sorry that I don't have the confidence to edit the article directly. A technology brief has been published by Apple here http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090608.pdf --Tim Bedford 82.68.152.188 (talk) 15:02, 9 June 2009 (UTC)

Examples

I have added an examples section based on the Ars Technica review. -- Axman6 (talk) 11:29, 2 September 2009 (UTC)

C, C++, Objective-C extensions

As far as I know, Apple didn't add extensions to C, C++ and Objective-C. They added the extension only to C. The blocks also work on C++ and Objective-C (on Apple's implementation) because they are supersets of C. Someone with a better knowledge should edit it if I am indeed correct —Preceding unsigned comment added by 91.132.214.177 (talk) 22:25, 11 September 2009 (UTC)

C++ is a language descended from C, but it's not a superset - some valid C code is not valid C++ code. It's probably clearest to say that blocks were added to all three languages. Guy Harris (talk) 20:14, 13 September 2009 (UTC)

Serial Queues vs. Threads

People have been talking about GCD as if it were a replacement for threads. Apple's own articles sound like extensive PR, saying that "serial queues are more efficient" and so on. As far as I understand it, this is what it claims to be: a serial queue. Threads are for parallel processing. This is a queue wherein you can dispatch chunks of work to do serially. That means that these chunks of code when they share the same pieces of data cannot run concurrently... it's not a replacement for threaded programming and running serially is not "faster" than running in parallel. Apple is being weaselly when they say it is more efficient, yes, it is more efficient to be able to run without locks, however, if this means that you have to run your chunks of code in serial fashion you lose the whole point of parallel programming. It would seem that you can dispatch chunks of code to various queues where they would/could run in parallel, but again you have to know that they do not interfere with each other's data. In the threaded world, if you know this you don't have to engage locks either.

It would help to have someone who has come to grips with an in-depth knowledge in this subject matter to contrast the two to illustrate how they compliment and contrast each other. Very importantly, to do so without referring to a review like the Ars Technica review which is tripping over itself to praise apple, but from a neutral and analytical point of view so it can be viewed as a tool in the toolbox and help developers understand what will be an appropriate use for this.

You cannot get this information from Apple's writeups because Apple is clearly trying to convert developers who may be unsure with parallel programming that this is somehow a "faster, safer, more efficient" way to achieve parallel programming without dealing with those "scary threads." The two do not seem to occupy the same domain at all, and a representation of this model as the holy grail that solves all parallel programming problems (as one would get the impression reading the Ars Technica marketing, er, review document), would not seem to be accurate. —Preceding unsigned comment added by 76.65.181.248 (talk) 21:30, 12 September 2009 (UTC)

According to the linked pdf (btw it's a dead link. I'll update after this edit) GCD is not a serial queue. GCD is a daemon that always runs and knows what processes and threads are running system-wise, therefore being able to better allocate resources. Developers assign blocks to the global queues (which by default run the blocks in them concurrently) and GCD allocates these blocks to threads. Developers can create private queues, witch are serial (I am assuming you are talking about these queues) for cases where multiple blocks need to access the same data structures and cannot be run in parallel. —Preceding unsigned comment added by 91.132.214.177 (talk) 23:05, 12 September 2009 (UTC)

Almost everything above seems to completely miss the point as to what GCD was designed to do, which is provide "cheap serialization" of related operations while still allowing non-related ones to run concurrently with respect to one another and with no explicit thread management. This is why the comments above regarding which is "faster" is almost a non-sequitur, as are the general observations about serial vs parallel execution. GCD will run in parallel whatever you allow it to run in parallel, within the constraints of whatever else is currently being executed by the same process or by other processes on the system. No "daemon" is involved in the execution of GCD code. Nothing runs "all the time" unless there is actual work to be done, in which case that work is done in the most efficient way possible. Far from being the puff-piece that the author claims, Siracusa also got (and made) the point that the real benefit of GCD isn't even the execution paradigm so much as the combination of blocks and a relatively minimalistic design aimed at allowing programmers to easily make the switch from single to multi-threaded programming by simply "pushing things into the background" as a first order attempt. Code that makes no use of threading whatsoever because manually managing the life-cycle of pthreads is annoying is really GCD's first and primary target. Those who are merely speculating about what GCD does vs working from a position of hard facts are also encouraged to actually check out the OSS project for libdispatch and see for themselves simply by reading the code and associated documentation. —Preceding unsigned comment added by 208.106.35.98 (talk) 20:08, 2 April 2011 (UTC)

Open Source Library

Apparently Apple has released Grand Central Dispatch as an Open Source library known as libdispatch. It is released under the Apache License. Madd the sane (talk) 06:17, 13 September 2009 (UTC)

Closures

Article says: ""Blocks" are an extension to the syntax of C, C++, and Objective-C programming languages that encapsulate code and data into a single object in a way similar to a closure.[4]"

What does "in a way similar to a closure" mean here? (Either it has closure semantics or it doesn't, right?) I see no mention of the word "closure" in the linked PDF, and the Blocks_(C_language_extension) article indicates they do have closure semantics. Is there some specific limitation that should be mentioned here? —Preceding unsigned comment added by 204.16.40.113 (talk) 16:29, 24 February 2010 (UTC)

NULL

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, NULL) should be dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0)

That is in implementation the same thing (I believe). But the type is incorrect. We have an unsigned long here and not a pointer. I would like to correct it but it will then the citing will not be correct. How is that handled? — Preceding unsigned comment added by 89.247.82.172 (talk) 15:35, 11 July 2011 (UTC)

libdispatch for Windows

Safari for Windows is an interesting source of Windows ports of Mac-specific libraries. In particular, it has libdispatch.dll. Is it known how do Apple did this port? Aekton (talk) 16:25, 26 January 2013 (UTC)

iTunes for Windows has more recent version of libdispatch.dll. Safari 5.1.7 (the latest Windows version of Safari) ships libdispatch 1.109.7.10 (according to PE headers). iTunesSetup.exe or iTunes64Setup.exe can be unpacked to find AppleApplicationSupport.msi which can be installed on its own without iTunes. iTunes 11.1.3.8 ships libdispatch.dll 1.109.8.19. So far it can be said that Apple has "official" port of GCD for Windows, at least they maintain current version of libdispatch suitable for iTunes development. It is expected they continue this work (unless they happen to churn out all the code dependent on libdispatch). There are 2 problems with this port, however: no Win64 port and no publicly available Objective-C compiler for Windows with Apple API&ABI (GNUStep and Apple Objective-C compilers can't be mixed on Mac OS X and the same most likely goes to Windows). Given that objc.dll sources are open, one can use Foundation.dll, CoreGraphics.dll, and so on including libdispatch.dll from pure C, using objc.dll APIs. Maybe someone will modify GNUStep compiler to match Apple API&ABI, but more likely that Apple will publish their internal development eventually. OCTAGRAM (talk) 00:30, 5 December 2013 (UTC)

{{Manual}} tag

The subject of this article is a technical solution to a technical problem.The passage in question is already descriptive--as opposed to prescriptive--but may well strike the non-technical as somehow instructive. As a tool designed to maximise power and convenience, I submit that any non-technical description will necessarily sound like advocacy. --Patronanejo (talk) 01:01, 18 October 2013 (UTC)

Relationship between GCD and OpenMP and similar?

I'm new to a lot of these concepts, and I'm trying to understand where GCD fits into the wider group of technologies like OpenMP and similar. I think the article would be greatly improved with a short comparison section. Any takers? Maury Markowitz (talk) 13:31, 2 September 2015 (UTC)

goroutine

Is this similiar to Goroutines in Go (programming language)? If yes then I sugegest adding this to article. Kotz (talk) 09:59, 25 October 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Grand Central Dispatch. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20130504142911/http://developer.apple.com/library/mac/ to https://developer.apple.com/library/mac/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 09:22, 22 October 2017 (UTC)