What does POSIX mean that the thread is "suspended"?

In the commentary on a recent question, the question arose about at what point can one expect a request to cancel a pthreads thread with PTHREAD_CANCEL_DEFERRED canceled in order to act. Links to the standard and a little advocacy. I'm not really worried about whether I was mistaken in my comments on this, but I would like to be sure that I understand the provisions of POSIX correctly.

The most appropriate section of the standard says:

Whenever a thread has a cancellation enabled and a cancellation request has been made with this thread as a target, and the thread then calls any function that is a cancellation point [...], the cancellation request must be valid until the function returns. If the thread has cancellation enabled and the cancellation request is executed with the thread as the target, while the thread is paused at the cancellation point, the thread must be woken up and the cancellation request will be valid.

What does it mean that the thread will be “suspended”? POSIX explicitly defines the term for processes, but not, as far as I can define, for threads. POSIX document flow suspension, on the other hand, refers to the behavior of several functions, including but not limited to some of those related to synchronization objects. Should it then be concluded that they serve collectively as an appropriate definition of the term?

And since all this relates to the question that generated this query string, given that POSIX does not indicate the suspension of the thread as part of the behavior of read() , fread() or any of the shared files or I / O threads, if the thread does not have time due to blocking I / O, does this mean that it is "suspended" for cancellation purposes?

+8
c language-lawyer posix
source share
3 answers

A suspended stream is one that, as you say, is blocked on the socket being read, waiting for the semaphore to become available, etc.

Given that POSIX implementations differ in complex edges and that there is a possibility of blocking a thread in a function that is not a cancellation point, it may be that relying on canceling the code that needs to be ported has more problems than it costs.

I never used it, I always wanted the code to explicitly instruct the thread to stop (usually a message down the pipe or queue). This is very easy using serial communication processes or the Actor Model system.

Thus, cleaning can be done under its own control, freeing up memory, etc. as needed. I don’t know if the canceled thread will clear its memory (I suspect not), or there is an option for a type like at_exit () (maybe). In general, I think that the behavior of the application is more closely controlled if there is only one way to exit the stream.

== == EDIT

@JohnBollinger,

The language used If a thread has cancelability enabled and a cancellation request is made with the thread as a target while the thread is suspended at a cancellation point can be interpreted as IF a thread has cancelability enabled AND IF cancelled and IF implementation suspends blocked threads AND IF the thread is blocked THEN the thread shall be awakened... In other words, they leave it until the implementation of the POSIX subsystem.

The implementation of Cygwin select () does not (or at least not) causes the thread to pause. Instead, it generates a polling stream for a file descriptor to check signal-related activity due to the fundamental lack of anything like select () on Windows (it comes close, but not cigars. Win32 select () only works with sockets). The implementations of select () back in the 1980s also worked the same way.

Perhaps for such reasons, POSIX does not want to clearly determine when a thread is paused. Historically, many implementations of select () have been such as to make it a minefield for the standardization committee to tell when a thread may or may not be suspended. Of course, the difficulties caused by select () also apply to the process, but since POSIX really defines a paused process, it seems strange that they could not / did not extend the definition to threads.

Perhaps this is due to how the threads are implemented; you can probably have a POSIX implementation that does not use OS threads (a bit like the early ADA implementations in those days when the OS did not execute threads at all), and in such an implementation a blocked thread may not be suspended (in the sense of no processor cycles) .

+3
source share

Definition of suspension in the context of threads:

3.107 Condition Variable

A synchronization object that allows a thread to pause execution, repeatedly, until some related predicate becomes true. A thread whose execution is suspended on a condition variable is considered blocked in the condition variable.

From: http://pubs.opengroup.org/onlinepubs/9699919799/

This is not a direct answer, just a definition - too big for comment. Blocked == paused.

+2
source share

read, fread and friends are system calls, and therefore they will execute a context switch and execute from the kernel context until these functions are completed. Interrupting the kernel context is beyond the scope of pthreads, so they will not cause cancellation.

I don't have a link for it, but as far as I know, streaming suspension in the context of Posix streams is associated with a synchronization object (e.g. futex).

+1
source share

All Articles