I know there is an api called pthread_join, but I don't wanna my thread suspend by any thread.... Any non-blocking method exists?
There's no POSIX API call, but you could easily implement it yourself, by using a dedicated bool exited; variable for each thread, having the thread set it to true upon exit and examining it in the other thread, both under the protection of a mutex.
Related
I'm implementing an iOS app which make requests using REST service. And I want to cancel all the previous REST calls when I make a new call. Can I do it in the global queue in GCD without Operation Queue? Thanks
GCD does not provide an API to cancel blocks. So you will have to implement this cancellation yourself.
The easiest way probably would be to set a global flag 'canceled' and check that inside of your blocks. If the flag is set, immediately return from your block. Then after all blocks have finished you can reset the flag and enqueue your new block.
Even though that sounds simple, this requires some nontrivial code. It would be much easier to use NSOperationQueue instead of reimplementing its features on top of plain GCD.
I am trying to atomically execute following set of statements
[inspectionLiteApi setBusinessObject:inspectionSourceObjectApi];
if (![inspectionSourceObjectApi.inspectionLites containsObject:inspectionLiteApi])
[inspectionSourceObjectApi addInspectionLitesObject:inspectionLiteApi];
These statement can be called from multiple thread. But i want each thread to access them atomically. What is the proper way. I have searched for NSLock but using NSLock has following issue:
Warning: The NSLock class uses POSIX threads to implement its locking
behavior. When sending an unlock message to an NSLock object, you must
be sure that message is sent from the same thread that sent the
initial lock message. Unlocking a lock from a different thread can
result in undefined behavior.
Regarding the use of
dispatch_semaphore_create
dispatch_semaphore_signal
and
dispatch_release
I couldn't understand how to use them. Can any one guide me?
I created this thread in my iOS app, and I'd like to stop it:
dispatch_queue_t myDispatch = dispatch_queue_create("com.myqueue", DISPATCH_QUEUE_CONCURRENT);
myDispatch thread within it invokes dispatch_global_queue and dispatch_main_queue respectively to execute heavy operations and to execute graphics operations.
But in response to a user action in the app can be called another function that uses another queue very similar to myDispatch. If myDispatch thread is terminated, there are no problems, but this call can also occur during the execution of myDispatch thread, and so my app crashes because both thread use the same arrays.
There is a way to stop or kill a thread before its termination? I'd like to kill the thread currently running and start the new thread.
If you want to cancel/stop background work you should be using NSOperation since as far as I know once you dispatch a block with GCD you lose control of it.
To cancel a GCD thread you have to use your own atomic flag.
I am looking for an equivalent pattern in multi-threading in iOS as there is in .NET for pulse and wait. Essentially, I want a background thread to lay dormant until a flag is set, which essentially "kicks" the thread into action.
It is an alternative to a loop+thread.sleep(). The flag can be set on a different thread than the actual background thread doing the processing. Thanks!
There are a variety of different mix-and-match thread APIs available on iOS and OS X. What are you using to create your thread?
The simplest suggestion is to use a Grand Central Dispatch (GCD) semaphore.
Setup code:
dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
// Then make sure your thread has access to this semaphore
Thread code:
dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
// Will block forever until the semaphore is triggered
Trigger code:
dispatch_semaphore_signal(semaphore);
An even better suggestion: GCD already manages its own thread pool, so just take advantage of it instead of spinning up your own thread. It's very easy to use dispatch_async to run some code in a background thread.
I'm not familiar with this pattern in .NET, but it is generally a bad idea to purposefully lock a thread (unless that thread cannot continue, but it sounds like you want it waiting most of the time or at least for long periods of time).
This is bad for the scheduler, bad for system resources.
You can use NSThread's +detachNewThreadSelector:... method to make a new thread. And you can use a variety of ideas to try to manage your logic for creating and maintaining such a thread in a single place like NSObject's -performSelectorOnMainThread:...
Here's the situation, I have a thread running that is partially controlled by code that I don't own. I started the thread so I have it's thread id but then I passed it off to some other code. I need to be able to tell if that other code has currently caused the thread to block from another thread that I am in control of. Is there are way to do this in pthreads? I think I'm looking for something equivalent to the getState() method in Java's Thread class (http://download.oracle.com/javase/6/docs/api/java/lang/Thread.html#getState() ).
--------------Edit-----------------
It's ok if the solution is platform dependent. I've already found a solution for linux using the /proc file system.
You could write wrappers for some of the pthreads functions, which would simply update some state information before/after calling the original functions. That would allow you to keep track of which threads are running, when they're acquiring or holding mutexes (and which ones), when they're waiting on which condition variables, and so on.
Of course, this only tells you when they're blocked on pthreads synchronization objects -- it won't tell you when they're blocking on something else.
Before you hand the thread off to some other code, set a flag protected by a mutex. When the thread returns from the code you don't control, clear the flag protected by the mutex. You can then check, from wherever you need to, whether the thread is in the code you don't control.
From outside the code, there is no distinction between blocked and not-blocked. If you literally checked the state of the thread, you would get nonsensical results.
For example, consider two library implementations.
A: We do all the work in the calling thread.
B: We dispatch a worker thread to do the work. The calling thread blocks until the worker is done.
In both cases A and B the code you don't control is equally making forward progress. Your 'getstate' idea would provide different results. So it's not what you want.