How can I create a "terminating" state in UPPAAL? If there is no edge from a state the execution will stop with deadlock. If the state has a loop without any guard the execution has never stopped. What is the best way to stop the Simulator execution without deadlock (if there is)?
No there isn't any specific terminating state.
Check out the comments below the question for more details.
Related
The kernel code can explicitly put the process to sleep if it's waiting for some task to occur. Now, if the task is put in TASK_INTERRUPTIBLE state, it can wake either by explicit wake up call or by receiving a signal.
Let's say another process issued a signal to a process which is in the wait queue and in TASK_INTERRUPTIBLE state, it will put the process into TASK_RUNNING and the signal will be handled when the process is scheduled next. Is this correct?
An explicit wake up call by other process can also be used to wake up the slept processes. I am wondering how could another process know when the condition became true for the slept process to wake up? Suppose a disk i/o is to be completed and so the process is put to sleep. How could another process know that the i/o is completed? Or is it done by kernel threads?
What am I missing?
It is up to the code that entered the interruptible state to detect the interruption and take appropriate action when it wakes. That might involve the code that is currently handling the user operation completing it with a -ERESTARTSYS error that will be intercepted and dealt with before the system call returns to user mode.
The code that has completed some I/O can just issue a "wake up" to the queue it is responsible for without caring whether there is any task on the queue to be woken up, or the exact condition the task is waiting for.
The task that is woken up needs to decide what to do, and that could include repeating the wait if the the condition it is waiting for had not been satisfied.
I did not understand the paradigm run-to-completion about state machine (14.2.3.9.1 UML 2.5 spec). At one point he says:
"Run-to-completion means that, in the absence of exceptions or asynchronous destruction of the context Classifier object or the StateMachine execution, a pending Event occurrence is dispatched only after the processing of the previous occurrence is completed and a stable state configuration has been reached. That is, an Event occurrence will never be dispatched while the StateMachine execution is busy processing the previous one"
and in another:
"IMPLEMENTATION NOTE. Run-to-completion is often mistakenly interpreted as implying that an executing StateMachine cannot be interrupted, which, of course [of course?? NDR] would lead to priority inversion issues in some time-sensitive systems. However, this is not the case; in a given implementation a thread executing a StateMachine step can be suspended, allowing higher-priority threads to run, and, once it is allocated processor time again by the underlying thread scheduler, it can safely resume its execution and complete its event processing"
So, is possible or not interrupt the state machine?? A new high priority event can interrupt the current event dispatch?
Thanks
Mauro
The implementation note refers to hard- or software implementation on a higher level. The completion is only valid for the context of the state machine. This machine may run in a global context which can allow to interrupt the processing of the state machine. But the state machine will not notice this interruption and from its own view it still continues processing. So, as mentioned, the only issue is that the state machines personal watch will not run continuously but with irregular jumps. In normal business processes this can be neglected, but when dealing with real-time-processing, you might get into trouble.
"an Event occurrence will never be dispatched while the StateMachine execution is busy processing the previous one" means that a StateMachine will not select the next Event from its queue until its run-to-completion step is completed. This does not prevent the state machine itself or other state machines from sending further events into its queue, while the run-to-completion step is running.
Moreover, a run-to-completion step might become suspended in the case of a synchronous Operation Call; the run-to-completion step will later be resumed when the operation call is completed (possibly returning a value).
The term "cancelling a pthread" and "exiting a pthread" looks confusing.
Can someone help me clearly explain the difference between the two?
P.S: Please don't help me with a link to the man pages, i have already seen that :-)
Added:
1) How are the thread data structures handled, and the cleanup
different in both these cases?
2) When there are signals pending for a thread, how are the pending
signals mask handled in both these cases?
Referring the 1st question in the OP's addendum, verbatim from man pthread_cancel():
When a cancellation requested is acted on, the following steps occur for thread (in this order):
Cancellation clean-up handlers are popped (in the reverse of the order in which they were pushed) and called. (See pthread_cleanup_push(3).)
Thread-specific data destructors are called, in an unspecified order. (See pthread_key_create(3).)
The thread is terminated. (See pthread_exit(3).)
The above steps happen asynchronously with respect to the pthread_cancel() call; the return status of pthread_cancel() merely informs the caller whether the cancellation request was successfully queued.
After a canceled thread has terminated, a join with that thread using pthread_join(3) obtains PTHREAD_CANCELED as the thread's exit status. (Joining with a thread is the only way to know that cancellation has completed.)
The only difference I see is the exit point: For a cancelled thread it's any cancellation point the thread function might pass, else it's pthread_exit(), return or the end of the thread function.
Update (referring the 2nd question):
I'd say if a signal was put into a thread's queue and still is pending when cancellation has finished the signal is lost. I'm not sure but I could imagine that signal processing is going on as long as the thread lives, that is also "during" the cancellation.
All I could find regarding this is from man pthread_exit:
BUGS
Currently, there are limitations in the kernel implementation logic for wait(2) ing on a stopped thread group with a dead thread group leader. This can manifest in problems such as a locked terminal if a stop signal is sent to a foreground process whose thread group leader has already called pthread_exit(3).
All quotes are comming from the Debian (non-free) package manpages-posix-dev (2.16-1) . (The source package is here.)
I've got a service that I need to shut down and update. I'm having difficulties with this in two different cases:
I have some threads that sleep for large amounts of time. Obviously I can't wait for them to wake up to finish shutting down the service. I had a thought to use an AutoResetEvent that gets set by some controller thread when the sleep interval is up (by just checking every two seconds or something), and triggering it immediately at OnClose time. Is there a better way to facilitate that?
I have one thread that makes a call to a blocking method call (one which I cannot modify). How do you signal such a thread to stop?
I'm not sure if I understood your first question correctly, but have you looked at using WaitForSingleObject as an alternative to Sleep? You can specify a timeout as well as an object to wait on, so if you want it to wake up earlier, just signal the object.
What exactly do you mean by "call to a blocking thread"? Or did you just mean a blocking call? In general, there isn't a way to interrupt a thread without forcefully terminating it. However, if the call is a system call, there might be ways to return control by making the call fail, eg. cancelling I/O or closing an associated handle.
For 1. you can get your threads into an interruptable Sleep by using SleepEx rather than Sleep. Once they get this shutdown kick (initiated from your termination logic using QueueUserApc), you can detect it happened using the return code from SleepEx and terminate those threads accordingly. This is similar to the suggestion to use WaitForSingleObject, but you don't need another per-thread handle that's just used to terminate the associated thread.
The return value is zero if the
specified time interval expired.
The return value is WAIT_IO_COMPLETION
if the function returned due to one or
more I/O completion callback
functions. This can happen only if
bAlertable is TRUE, and if the thread
that called the SleepEx function is
the same thread that called the
extended I/O function.
For 2., that's a tough one unless you have access to some resource used in that thread that can cause the blocking call to abort in such a way that the calling thread can handle it cleanly. You may just have to implement code to kill that thread with extreme prejudice using TerminateThread (probably this should be the last thing you do before exiting the process) and see what happens under test.
An easy and reliable solution is to kill the service process. A process is the memory-safe abstraction of the OS, after all, so you can safely terminate one without regard for process-internal state - of course, if your process is communicating or fiddling with external state, all bets are off...
Additionally, you could implement the solution which OS's themselves commonly do: one warning signal asking the process to clean up as best possible (which sets a flag and gracefully exits what can be gracefully stopped), and then forceful termination if the process doesn't exit by itself (which ends pesky things like blocking I/O).
All services should be built such that forceful termination isn't harmful, since these processes are system managed and may be terminated by things such as a reboot - i.e., your service ideally should permit this without corrupting storage anyhow.
Oh, and one final warning; windows services may share a process (I presume for efficiency, though it strikes me as an avoidable optimization), so if you go this route, you want to make sure your service is not sharing a process with other services. You can ensure this by passing the option SERVICE_WIN32_OWN_PROCESS to ChangeServiceConfig.
A deadlock normally means that thread (or process) A is waiting for thread B, and at the same time thread B is waiting for thread A.
Currently I encountered a similar situation in our application. Thread A is waiting for an event to be set by thread B. However, thread B is not waiting for thread A, it just won't set the event (no matter for what reason). I am wondering whether this situation can also be called a "deadlock", or is there an other term for this?
I'd call it a bug or bad design. But it is not deadlock if one thread is still running.
Strictly speaking, no that's not deadlock, which is what you initially said (except that in general there could be a whole cycle of threads each waiting for the next one's lock: A->B->...->Z->A).
I think you could call it resource starvation, but that's quite a general term that also covers deadlock.
I would call it a starvation (ressource being CPU), not a deadlock.
Yes - I would call this a deadlock, too.
However, only one thread (Thread A) is affected from it, not the entire application.
Here is my point of view :
A deadlock is a situation where the global state of the program does not progress anymore.
If A is blocked but the program can still terminate because B may find a solution, it is not a deadlock.