There are two cancel type in pthread:
PTHREAD_CANCEL_DEFERRED
A cancellation request is deferred until the thread next calls a function that is a cancella‐tion point
PTHREAD_CANCEL_ASYNCHRONOUS
The thread can be canceled at any time.
My problem is how PTHREAD_CANCEL_DEFERRED is implemented and what happened at the cancellation point function like read, write ...
Why does the thread not execute the code after the cancellation point function, how to do this? Whether the operating system supports it？
Related
I know that if a thread is PTHREAD_CANCEL_ENABLE, then it can be canceled, and pthread_cancel(pthread_t thread) will send a cancellation request to the specified thread, and the reaction of the thread depend on the following 2 attributes:
if the cancellation type is PTHREAD_CANCEL_ASYNCHRONOUS, cancellation requests are acted on immediately.
if the cancellation type is PTHREAD_CANCEL_DEFERRED, cancellation requests are acted on as soon as the thread reaches a cancellation point.
I just want to know what happened at the cancellation point and in the signal handler, and how it can respond to the cancellation request at the cancellation point. I know pthreads use signals to implement this, but I do not know the details. This problem bothered me for a long time!!!
Wish you guys could help me, thanks a lot for your answers!!!
I am trying to understand Posix threads. In the man page of pthread_cancel(), it is mentioned that "thread’s cancelability state, determined by pthread_setcancelstate(), can be enabled or disabled. If a thread has disabled cancellation, then a cancellation request remains queued until the thread enables cancellation.
But when I was reading about thread cancellation points on http://www.makelinux.net/alp/029, it is mentioned that if we set the cancel type as disabled (uncancellable), the cancellation requests are quietly ignored.
Can any one please let me know whether cancellation requests are getting queued or ignored if we set the cancellation type as DISABLED?
POSIX threads controls thread cancellation by a combination of two binaries variables:
cancellation STATE and cancellation TYPE. The associated functions are pthread_setcancelstate() and pthread_setcanceltype() accordingly.
When the STATE is set to disabled, the cancellation request is ignored.
It is not thrown out, it is suspended (or as you correctly wrote - "queued"), until the STATE is set back to enabled. Since the state is enabled, the OS starts the cancellation process according to the cancellation type. If you have a code that must be executed before a thread is cancelled (e.g. memory de-allocation etc.), you may set the thread cancellation state to disabled, before entering the code, and enable the cancellation exiting the code. The second question is how and when the thread is really stopped (cancelled). The the cancellation type answers this question. If the type is set to (not recommended) asynchronous, the cancellation may occur at the nearest instruction. If the type is set to the default deferred cancellation, the cancellation will occur at the next "cancellation point", a POSIX function that checks thread cancellation status and terminates the thread.
In a typical ASIO or event-based programming library like libevent, is there a way to set a deadline for each callback?
I am worried about possible infinite loops within the callbacks. Is there a way to gracefully detect them, remove the misbehaving callback from task queue and continue processing other tasks in the queue?
I can think of a way to detect it through an external thread and kill the event-loop thread and create a different thread but I am trying to see if there are any other commonly used methods. I believe this is a problem which someone has faced at some point of time and thought through a solution
There is no general way to unstick a thread without its cooperation, whether it's running a callback or not. The thread may hold critical locks or may have acquired resources that would never get released if the thread was somehow coerced to stop from the outside.
If you really do need this functionality, then all code that could potentially be interrupted must be designed to support some specific method of interruption. You can start a deadline timer when you enter the callback and cancel it when you're finished. The deadline timer would have to trigger the thread's interruption mechanism. You'd need at least one other thread running the I/O service in order for some thread to run the timer handler while the callback was running in another thread.
You can also isolate the code in its own process with some kind of wrapper. Then if the code fails to terminate, you can kill the process from the outside.
This question already has answers here:
asynchronous and non-blocking calls? also between blocking and synchronous
(15 answers)
Closed 4 years ago.
I am reading 'Operation System Concepts With Java'. I am quite confused by the concept of
blocking and synchronous, what are the differences between them?
Blocking may or may not be the same as synchronous, depending on the context. When we talk about method calls, then a synchronous call can also be said to be blocking (I'll get back to this in a bit), because the thread calling the method cannot proceed forward until the method returns. The antonym in this case would be asynchronous.
In lock terminology, a lock is said to be blocking if the thread waiting to acquire it is put in a suspended mode until the lock becomes available (or until a timeout elapses). The antonym in this case is a non-blocking lock, meaning that the thread returns immediately even if it cannot acquire the lock. This can be used to implement the so called spinning lock, where you keep polling the state of the lock while keeping the thread active.
Having said this, you can extrapolate the difference between the concepts: synchronous generally means an activity that must wait for a reply before the thread can move forward. Blocking refers to the fact that the thread is placed in a wait state (generally meaning it will not be scheduled for execution until some event occurs). From here you can conclude that a synchronous call may involve blocking behavior or may not, depending on the underlying implementation (i.e. it may also be spinning, meaning that you are simulating synchronous behavior with asynchronous calls).
Blocking - operation are said to have blocking behavior if it waits for some event to get complete. For example: if a lock is not available a thread may enter a wait state on event till lock is available. Such an operation is said to be blocking.
Synchronous - Synchronous call can be easily understood with an example of http protocol where client waits for reply from server an then proceeds. Synchronous call can be blocking or non blocking.
Asynchronous - A method can asynchronous call other method. After a call it can continue to execute its next instruction. When called method completes it execution it will send an reply/callback to caller method of it's success or failure.
Non-blocking - Non blocking behavior is like checking the condition at that instance. For example- in case of locks if it is not available it will not wait till it is available like blocking operation. Also we need to repeatedly check the availability of locks as there will be no callback like asynchronous calls.
Summary:
Blocking is always synchronous.
Synchronous call have blocking operations if it waits for some event to get complete, caller method may enter wait state.
Synchronous call is non blocking, if it repeatedly check for some event to occur before proceeding for next instruction. Caller method does not enter wait state on some event to complete.
Asynchronous call cannot be blocking and it involves callback from called method which needs to handle.
I would classify them as follows:
Blocking - Thread will wait on action untill success or failure (highlight on 'will wait', failure is commonly a timeout)
Synchronous - Thread will complete the action, either by success or failure, before reaching any line after it (highlight on action completion)
Non-blocking - Thread will not wait to complete the action, executes action immediately
Asynchronous - Another thread (either logical or physical) will complete the action or inform it is ready using a callback, will not wait before performing following commands.
Note: from here the name asynchronous originates, since you cant be sure in which order the commands will execute
synchronous means that the work is done in the thread that calls the function and the method does not return until it is finished.
asynchronous methods return immediately because another thread does the work and raises a flag or fires an event when the work is done.
blocking means that the thread executing a blocking event will wait until the event has occurred. for example you try to read from a socket and none sends you a message. the blocking call will not return until the message has been revived from the socket.
well and nonblocking means the opposite to blocking with implies that nonblocking calls are asynchronous.
This seems like a silly question, but I can't find the answer to it anywhere I look. I know that in UNIX, signals are handled asynchronously. If I write a function that handles a signal, where is that function run? Is a new thread spawned? Is an existing thread interrupted somehow? Or is this handled in a system thread like asynchronous I/O is?
A signal function is executed as if a thread in the process has been interrupted. That is, the signal handler is called using the signaled thread and the stack is rearranged so that when the signal handler returns the thread continues execution. No new threads are introduced.
An existing process thread is interrupted until the function returns. There are serious restrictions on what it can safely do to ensure it doesn't corrupt state of function calls the thread was in the middle of - specifically, any functions it calls that the thread may have already been calling must be async reentrant. See the man pages e.g. signal, sigaction for further details or ask more specific questions as you like.
It's not a separate thread, but your code is hastily suspended. That's why only a limited subset of the POSIX calls is available.
From the signal man page:
The routine handler must be very careful, since processing elsewhere was interrupted at some arbitrary point. POSIX has the concept of "safe function". If a signal interrupts an unsafe function, and handler calls an unsafe function, then the behavior is undefined. Safe functions are listed explicitly in the various standards.