Well I have an application that uses both Objective C & c++ but for portability reasons I have tried to use c++ as much as possible.... Now I am confronted with some problem that requires threads I was thinking of using pthread instead of NSThread... is it Okay to use pthread? Will Apple punish me for using it by rejecting my app on the appstore...?
NSThread is built around pthread anyway
I can't see any reason why using pthread would lead to rejection from Apple's part
NSThread is mostly a wrapper around pthread semantics.
Advantages:
- NSThreadWillExitNotification notification when NSThread exits
- A NSMutableDictionary thread-local storage
Limitations:
- you can only create detached NSThread
Be aware that Cocoa needs to know that you want to do multi-threading. It is important to first detach a dummy NSThread so the application can be considered multi-threaded.
My app uses pthread API, changes the scheduling policy from SCHED_OTHER to SCHED_FIFO, and changes thread's priority.
It works well.
However, I avoid using Cocoa touch framework APIs in the thread because I don't know the side effect of pthread instead of NSThread.
Related
It says that Unity is not thread-safe. What does this exactly imply? If I have a multithreaded C++ DLL that I want to import and use in Unity, is there a procedure to make it compatible?
This is no problem, actually the single-thread limitation is typical for almost all user interface implementations. There are multiple ways how you can solve your problem. I don't know which solution is the best for Unity, I am just providing this as an example how you can proceed: You can for example have a single UI thread and call all Unity-related stuff only from this single thread. Use all other threads for whatever you want and let them communicate with your UI thread. The UI thread is then also de-facto mediator between Unity and the rest of your application.
I want to use, say, QSemaphore with boost threads or c++ 11 threads. Is that allowed?
I'm working on pqConsole, where multithreading plays an important role.
Running a console for SWI-Prolog (multithreaded, implemented in C), the Qt GUI manages IO on behalf of user programs, executing in a background QThread, where the foreign language interface is instanced.
Threads can also be initiated from C side, and they get a dedicated console (see interactor/0), where the IO again is rendered on Qt GUI.
I'm using QMutex and QMutexLocker to syncronize (i.e. the simpler constructs), and AFAIK those are performing as expected.
Theoretically, yes, you can.
Note, you could also just use the boost semaphore available with that scenario. Also, QSemaphore currently does not use the pthread interface underneath, but some custom solution. There were discussions to refactor that later for utilizing the pthread features more.
I'm new to wxWidgets (C++), and threads for that matter. What should I be aware of concerning shared resources? Should I implement some sort of semaphore-based locking of resources that may be used by both the GUI thread and the worker thread(s)? Does wxWidgets offer some capability for dealing with this?
Not sure what your choice of threading library is at this point but in your case I'd use wxThread (see here & here for documentation).
What should I be aware of concerning
shared resources?
See the Important notes for multithreaded applications part here for wxWidgets specific multi-threading issues.
Other than that the 'usual' concerns about shared resources apply.
Should I implement some sort of
semaphore-based locking of resources
that may be used by both the GUI
thread and the worker thread(s)? Does
wxWidgets offer some capability for
dealing with this?
wxWidgets already implements a number of synchronization objects, see here.
As a side note prefer using the RAII locker helpers (wxMutexLocker, wxCriticalSectionLocker) instead of explicitly acquiring/releasing.
In Cocoa, is NSThread faster than pthread? is are any performance gain? is it negligible to ignore?
I have no data to back this up, but I'm going to go out on a limb and say "they're equivalent". NSThread is almost certainly wrapper around pthread (is there really any other way to create a system thread?), so any overhead of using NSThread versus pthread would be that associated with creating a new object and then destroying it. Once the thread itself starts, it should be pretty much identical in terms of performance.
I think the real question here is: "Why do you need to know?" Have you come up against some situation where spawning NSThreads seems to be detrimental to your performance? (I could see this being an issue if you're spawning hundreds of threads, but in that case, the hundreds of threads are most likely your problem, and not the NSThread objects)
Unless you have proof that the creation of an NSThread object is a bottleneck in your application, I would definitely go with the "negligible to ignore" option.
pthreads actually have slightly less overhead, but I can't imagine it will make any difference in practice. NSThread uses pthreads underneath. The actual execution speed of the code in your thread will be the same for both.
Under iPhone SDK, NSThread uses pthread as an actual thread. Frankly, they're equivalent.
However, we can access "deep" settings via pthread APIs if we use pthread API. For example, scheduling way, stack size, detached or not, etc. These API are hidden by NSThread capsule.
Therefore, under some conditions, pthreads win.
I would also guess that any "overhead" or "instantiation difference" you pay as an extra for NSThread, would be evened by the extra cycles and calls you will eventually need to perform, to configure your pthread correctly, using pthread APIs.
I believe the NSThread is nothing but convenience wrapper that saves some coding in Cocoa/Cocoa-touch applications that want to be multithreaded.
I have discovered through trial and error that the MATLAB engine function is not completely thread safe.
Does anyone know the rules?
Discovered through trial and error:
On Windows, the connection to MATLAB is via COM, so the COM Apartment threading rules apply. All calls must occur in the same thread, but multiple connections can occur in multiple threads as long as each connection is isolated.
From the answers below, it seems that this is not the case on UNIX, where calls can be made from multiple threads as long as the calls are made serially.
From the documentation,
MATLAB libraries are not thread-safe.
If you create multithreaded
applications, make sure only one
thread accesses the engine
application.
When I first started using the engine, I didn't run across any documentation on thread safety, so I assumed that it was not thread-safe.
I use a C++ class to synchronize access to an engine instance. For more parallel processing designs, I instantiate multiple instances of the engine class.
(edit) I'm using MATLAB R14 on Solaris. I open the engine using the 'engOpen' call, and close it using 'engClose'. My platform does not crash when the Close is called by a different thread than the one that called Open.
From a user's perspective, Matlab's interpreter is purely single-threaded. To be safe, you probably need to make all access to the engine from a single thread.
Note that internally, Matlab uses plenty of threads. There are GUI threads, and in the last few versions, the interpreter can use multiple threads behind the scenes. But, the interpreter is semantically equivalent to a single-threaded interpreter (with interrupts).
You can use engOpenSingleUse instead of using engOpen to make more than one thread working separately. (Only Windows)