I’m curious what DispatchQueue really is under the hood, I tried to google this information but all the documentation is rather abstract and doesn’t provide any real information about the implementation. In my understanding DispatchQueue is some kind of an entity that exists somewhere and is able to store blocks of code and is controlled directly by the kernel(by GCD which is baked into the kernel) which is able to inject those blocks in chosen(by GCD/Kernel) thread. This this the correct vision of DispatchQueue, or I misunderstood something?
You've misunderstood, at least in some parts. GCD is not "baked into the kernel", it's a library that runs on top of POSIX threads, which are OS-level primitives with kernel support. GCD is simply a set of APIs that make it easier for developers to do work on multiple threads without having to manage the threads themselves.
For what it's worth, you can see the source code for GCD. It's here: https://opensource.apple.com/tarballs/libdispatch/ That said, it's full of micro-optimizations that take advantage of obscure compiler features (branch prediction directives and things like that) and it can often be hard to read and understand, even for experienced systems programmers.
A full-detail explanation of GCD's inner workings is beyond the scope of a StackOverflow answer, but I'll try to cook up a one or two paragraph explanation.
GCD manages some number of POSIX threads behind the scenes that it will use to execute work in the desired way. It also maintains a number of data structures to organize that work, like "queues" which can be thought of as "lists of blocks of work to be done." There are also groups, which allow you to be notified when a list of work items is completed. There are also various IO mechanisms to allow asynchronous IO to be serviced with these work items. It may (or may not) use various kernel services (like threads, kqueues, etc) to manage parts of its workload, but those aren't specific to GCD.
At the end of the day though, there's little or nothing "special" or "blessed" about GCD. In fact, there are multiple ports of GCD to various other operating systems out there, like this one for Linux: http://nickhutchinson.github.io/libdispatch/ which should drive home the point that it's not something specific to the Darwin kernel. Put differently, you could write your own version of GCD from scratch without needing to recompile the kernel.
Related
Actually sometimes you are required to write some custom code to achieve some functionality, there would be 2 possible approaches there:
make your implementation by joining already given methods of
Objective-c
write your custom code
At that point I am confused which code base is better(in performance), that can only be decided if I luckily find Time-Complexity of Objective-c methods. So is there any way to know about it?
There are a lot of methods and functions you can call in the SDKs for iOS (and other Apple platforms), so this question is perhaps excessively broad.
But a discussion of time complexity is usually about algorithmic complexity, so we can restrict our scope to those calls that are the building blocks of algorithms where we measure time as a function of input size — that is, things like collection operations rather than, say, UIApplication registerForRemoteNotifications.
By and large, however, Apple doesn't talk much about the computational complexity of the high-level data structures in Cocoa. This probably has something do with Cocoa's design goals being strongly in favor of encapsulation, with simple interfaces hiding powerful, dynamic, and possibly adaptable implementations. Examining CoreFoundation — the open source implementations underlying the central bits of Cocoa, like collections — bears this out. Here's a great writeup on how NSArray is sometimes O(1) and sometimes not.
There's certainly something to be said for a philosophy where you're not supposed to care about the complexity of the tools you're using — tell it what you want to do, not how you want it done, and let it optimize performance for you, because it can second-guess you better than you can second-guess yourself. It goes well with a philosophy of avoiding premature optimization.
On the other hand, there's also some sense to a philosophy of having basic building blocks of enforced, predictable complexity so that you can more easily plan the complexity of the algorithms you build from them. Just to show that Apple seems to do it both ways, it appears this is the philosophy of choice for the Swift standard library.
I've done a fair amount of research over the past few days, but I'm not sure what the current best practice is for concurrent Core Data. The most relevant post seems to be this blog post, but in light of this analysis about the performance of different concurrency methods, it seems that the modern way with parent contexts might not be the best. Also, this example from Apple doesn't implement the best practice mentioned in Apple's own concurrency guide that recommends NOT using the default NSConfinementConcurrencyType.
In light of all of this, what is the simplest and best way to implement concurrency with Core Data? All I need is a background thread the do some long writes to Core Data without hanging up the UI. Code examples are appreciated.
As always, it really depend on what you are trying to accomplish.
"long writes" will hang your UI no matter the architecture you implement.
A write operation lock the DB file in the OS level and the sqlite engine level (if you use this kind of store), all pending read operations will have to wait for the write to end before they complete.
One of the most used optimisation methods is segmenting the database "load" process with multiple save operations (you shouldn't mind as this happen in the background).
So, to answer the question:
The simplest way for you, would probably be to use the architecture described in the blog post you mentioned (parent-child hierarchy). if you notice that this cause to much "stutter" for your UI, try to optimise your data load process or try a different architecture.
use instruments to find "bottle necks" in your application execution.
CodeData has "quirks"/bugs in every architecture that I know, and you will find them gradually, depending on your use of it.
My recommendation is to go with the parent/child context pattern. In the light of the sparse details you give (e.g. number of records, total volume of data, latency of delivery, etc). this seems to be the most flexible and proven solution that can also accommodate very large datasets.
Contrary to other claims, you can have a smoothly operating UI regardless of how long the "writes" are to your database. Obviously, that is what background threads are for. The mechanism to keep the UI fluid is through so-called notifications about data change. You can react to these gracefully without disturbing the user experience.
Your remark about NSConfinementConcurrencyType is correct. As stated in your source, it is there for backward compatibility, so you can just forget about it. Obviously, for concurrency you want to use NSPrivateQueueConcurrencyType when creating your context.
I'm having some problems with apparently getting wrong results from pthread_getspecific in a library that's designed to link into various iOS apps.
I see that Apple writes:
Cocoa and POSIX store the thread dictionary in different ways, so you cannot mix and match calls to the two technologies. As long as you stick with one technology inside your thread code, however, the end results should be similar. In Cocoa, you use the threadDictionary method of an NSThread object to retrieve an NSMutableDictionary object, to which you can add any keys required by your thread. In POSIX, you use the pthread_setspecific and pthread_getspecific functions to set and get the keys and values of your thread.
Does that mean that neither the Cocoa nor POSIX TLS functions can be expected to work in library code when we don't know whether the code that calls us is already using one or the other?
How does one get to store and retrieve a thread-local pointer robustly in these circumstances?
Is there a native Darwin TLS support API we should be using instead of either Cocoa or POSIX?
I believe the point that Apple's docs are making is that you cannot use pthread_setspecific to set a value and then expect it to be available in threadDictionary. I wouldn't expect them to directly interfere with each other; they're just separate.
That said, if this is iOS-specific code, then the strongly preferred way to manage this is with GCD rather than POSIX threads. GCD offers the equivalent of TLS in the form of dispatch_get_specific, dispatch_queue_get_specific and dispatch_queue_set_specific. But it also provides much better thread management than POSIX threads.
If you don't mind using C++, boost has thread_specific_ptr. It supports iOS. If you don't want to use C++, the implementation probably offers some hints on how to make it work without a lot of external dependencies.
I suspect my app is creating lots of threads using dispatch_async() calls. I've seen crash reports with north of 50 and 80 threads. It's a large code base I didn't write and haven't fully dissected. What I would like to do is get a profile of our thread usage; how many threads we're creating, when we're creating them, etc.
My goal is to figure out of we are spending all of our time swapping threads and if using an NSOperationQueue would be better so we have more control than we do by just dispatch_async'ing blocks all over willy-nilly.
Any ideas / techniques for investigating this are welcome.
Looks like you need to take a look at Instruments. Learn about it from Apple docs or WWDC sessions or wherever you want. There are many resources
Generally NSOperationQueues are definitely better if you need to implement some dependicies.
As Brad Llarson pointed there are a few WWDC sessions which are helpful in many cases. However besides optimizing your calls you should consider making your code more human readable and simply better. I haven't ever seen source code with as many as 80 queues on iOS. There must be something wrong with the architecture of app.
Let me know anyone if I am wrong.
If you are spinning that many threads, you are most likely I/O bound. Also, Mike's article is great, but it's quite old (though still relevant wrt regular queues).
Instead of using dispatch_async, you should be using dispatch_io and friends for your I/O requirements. They handle all the asynchronous monitoring and callbacks for you... and will not overrun your process with extraneous processing threads.
I have a c++ library which has functionality exposed to Lua, and am seeking opinions on the best ways to organise my lua code.
The library is a game engine, with a component based Game Object system. I want to be able to write some of these components as classes in Lua. I am using LuaBind, so I can do this but there are some implementation choices I must make, and would like to know how others have done it.
Should I have just one global lua_State, or one per object, one per scene, etc?
This sounds like a lot of memory overhead, but will keep everything nice and separate.
Should I have one GLOBALS table, or one per object, which can be put in place before a call to a member? This would seem to minimize the chances of some class deciding to use globals, and another accidentally overwriting it, with less memory overhead than having many lua_States.
Or should I just bung everything in the one globals table?
Another question involves the lua code ittself. Two strategies occur... Firstly shoving all class definitions in one place, loading them when the application launches, Secondly putting one class definition per file, and simply making sure that file is loaded when I need to instance it.
I'd appreciate anyone's thoughts on this, thanks.
While LuaBind is certainly very nifty and convenient, as your engine grows, so will your compile times, drastically.
If you already have, or are planning to add, a messaging system (which I heavily recommend, specially for networking), then it simplifies problems significantly. In this case, what you will need to do is simply bind a few key functions to interface with the messaging system. This will keep your compile times down, and give you a very flexible system.
Since you are doing a component based engine (Good choice BTW), It makes more sense to integrate scripting as an object component. This way, it usually makes more sense to make each scripting component a new coroutine that runs behavior for each particular object. You need not to worry about memory too much, Lua states are very light, and can be made really fast if you interface your memory manager with Lua.
If you implement scripting as a component, it is still a good idea to have global or per-level scripts loaded, (to coordinate event triggers by other objects, or maybe enemy spawning timers).
As far as loading scripts go, it would not be bad practice, to just load the scripts you will need for a level all at once, and keep them in a global table for fas accessing, loading of lua scripts is pretty fast, specially if you pre-compiled them.
One consideration is how you're planning to thread things. If you want to run the code for two Game Objects in parallel, for example, then they really ought to have their own separate lua_States so that they can both be running at the same time. (Of course, that also means that they can't really share any state, except via the C code where you'd need to be conscious of thread-safety.)
As to the Lua code, I'd recommend loading everything when the app launches (unless you really need to do "lazy" loading of your core classes on demand). It typically simplifies maintenance and debugging. And in the case of code being loaded that's no longer needed, the garbage collector will clean that up with a quickness. :-)