With pthread, we cannot join any thread.
What is the prerequisite and why is it there?
According to : https://man7.org/linux/man-pages/man3/pthread_join.3.html
The pthread_join() function waits for the thread specified by
thread to terminate. If that thread has already terminated, then
pthread_join() returns immediately. The thread specified by
thread must be joinable.
The pthread_join() function makes the calling thread wait for the end of another thread (which thread identifier is passed as first parameter). By default, any thread is joinable when you call pthread_create(). If you want to make a thread non joinable, you can specify this behaviour by passing some attributes to the pthread_create() function (cf. pthread_attr_setdetachstate()).
Related
I am using pthreads and i have this doubt whether a thread will be restarted again if it encounters the same create statement that created it?
Will a thread be restarted again if it encounters the thread_create statement again?
It'll create a new thread regardless of whether it's called by thread that itself was created via pthread_create.
Lets say i have a thread t1. What happens if encounters the create statement, pthread_create(&t1,NULL,func,NULL). How can a new thread be created if i have a unique thread identifier , say the name t1?
In this case, you are still creating new thread but just reusing/overwriting the previous thread identifier t1. Which means you can only call pthread_join on the second you created but lose the ability to pthread_join, change attributes of the first thread, and so on on the first thread. Note that this is still valid. But if this is your use-case, you are probably better off creating detached threads (either by setting the attribute before creating the first thread or by calling pthread_detach from the thread function). A detached thread can't be joined and whose resources are freed when the thread exits (i.e., either by calling pthread_exit or by returning from the thread function).
I don't want to execute the current instructions in the current processmessage loop, but instead execute it in the next processmessage loop. Is their a good way to do it ? TThread.queue seam to be what i m looking for except that TThread.queue can not be executed from the main Thread :( I m under firemonkey also if it's matter
TThread.Queue() is asynchronous only if it is called in a worker thread. When TThread.Queue() is called in the main thread, it is synchronous instead 1.
To do what you are asking for, you can use TThread.CreateAnonymousThread() or TTask.Run() to create a worker thread that then calls TThread.Queue().
1: please vote on RSP-15427 Add an option to let TThread.Queue() run asynchronously when called by the main UI thread.
I'm pretty clear what dispatch_async queue is performing, but I'm not clear what dispatch_sync purpose is. For an example: what is difference between this:
NSLog(#"A");
NSLog(#"B");
and this:
dispatch_sync(dispatch_get_main_queue(), ^ {
NSLog(#"A");
});
NSLog(#"B");
As I get, in both ways output will be A then B. Because sync is executed in order that is written. Thanks.
As the names says dispatch_sync makes it possible to synchronize the tasks to be executed even if they are not executed on the main queue.
Saheb Roy's answer is only half of the truth. You can only specify the dispatch queue your code should be executed on. The actual thread is chosen by GCD.
Code blocks dispatched using dispatch_async on a concurrent queue are also executed in the FIFO way and guaranteed to be executed in the order you dispatch them. The main difference is that dispatch_sync on a serial queue also guarantees you that following code blocks are not executed before the previous block has finished executing. dispatch_sync is blocking your current dispatch queue i.e. the queue your dispatch_sync call is executed on. So your calling function is blocked until the dispatched code block returns whereas dispatch_async returns immediately.
execution timeline using dispatch_async on a concurrent queue my look like this:
Block A [..............]
Block B [.....]
Block C [....]
while using dispatch_sync on a serial queue looks like this:
Block A [..............]
Block B [.....]
Block C [....]
The purpose of dispatch_syncqueue is that it will dispatch blocks of code in the thread you mentioned and that the will run synchronously, meaning one by one or rather one after the other in FIFO method.
Do check out NSOperationQueue to understand the function of dispatch_sync in a better way
According to Docs
Submits a block to a dispatch queue for synchronous execution. Unlike
dispatch_async, this function does not return until the block has
finished. Calling this function and targeting the current queue
results in deadlock.
Unlike with dispatch_async, no retain is performed on the target
queue. Because calls to this function are synchronous, it "borrows"
the reference of the caller. Moreover, no Block_copy is performed on
the block.
As an optimization, this function invokes the block on the current
thread when possible.
Its purpose is to the multitasking. .Two or more process run at a same time one in background thread and another in main thread. .mostly the process run in background thread and UI update in main thread to avoid screen block.
Let's say I hypothetically call a dispatch_sync from a concurrent queue - does it block the entire queue or just that thread of execution?
dispatch_sync will block the caller thread until execution completes, a concurrent queue has multiple threads so it will only block one of those on that queue, the other threads will still execute.
Here is what Apple says about this:
Submits a block to a dispatch queue for synchronous execution. Unlike
dispatch_async, this function does not return until the block has
finished. Calling this function and targeting the current queue
results in deadlock.
Unlike with dispatch_async, no retain is performed on the target
queue. Because calls to this function are synchronous, it "borrows"
the reference of the caller. Moreover, no Block_copy is performed on
the block.
As an optimization, this function invokes the block on the current
thread when possible.
Source
As far as I understand, pthread_exit() exactly equals to return when you need terminate a thread with a return value. When people can use the consistent way, i.e. return, to do the job why Pthread define such a duplicated interface?
Two reasons that come to my mind: pthread_exit
Allows you to exit a thread from any depth in the call stack.
Must be called on the main thread if the TLS keys for the main thread are to have their free functions called. And here as well: "Any cancellation cleanup handlers that have been pushed and not yet popped are popped in the reverse order that they were pushed and then executed. After all cancellation cleanup handlers have been executed, if the thread has any thread-specific data, appropriate destructor functions will be called in an unspecified order... An implicit call to pthread_exit() is made when a thread other than the thread in which main() was first invoked returns from the start routine that was used to create it. The function's return value serves as the thread's exit status."
If you're going to call pthread_exit a duplicated interface, then you should also call exit() a duplicated interface, since you could exit the program at an arbitrary point. You probably want to call pthread_exit() when you have some sort of error condition where you simply cannot continue. Or, alternatively, you've found whatever value you're looking for inside of the thread.
As for it's real existence, according to the documentation:
An implicit call to pthread_exit() is made when a thread other than the thread in which main() was first invoked returns from the start routine that was used to create it. The function's return value serves as the thread's exit status.
So if you did a return <some pointer> from the thread, or simply reached the end, pthread_exit() would be called anyway. It's the same with exiting from main(), if you return 0 you're actually calling exit(0). The function has to exist, otherwise the kernel would not have a way of determining if the thread exited.