Could someone please explain how the Cursive Clojure plugin in IntelliJ behaves when in the REPL it encounters a blocked thread. It looks like instead of blocking the current thread it pushes its execution onto a new thread (judging by the enabled stop icon) which, when clicked on, results in interruption of that thread and one can continue issuing commands in the original thread:
Would that be a correct assumption or am I missing something? The behavior seems different from a regular Clojure REPL. Thank you.
Related
I have a multithreaded application running on WIN32 which uses a semaphore to protect a linked-list. Very occasionally this locks-up. When it locks-up I can stop the application in cppvsdbg under Visual Studio Code and I can see that two of the threads are waiting on the semaphore, i.e. they are blocked at:
WaitForSingleObject(handle, INFINITE);
However, the third thread is blocked here:
ReleaseSemaphore(handle, 1, NULL);
...i.e. it seems to have blocked on ReleaseSemaphore(), the very function which of course would allow one of the other two threads to run. If I single step in the debugger, or I set a break-point just beyond the ReleaseSemaphore() call and continue running, nothing budges, the application remains locked up. The thread that is blocked at ReleaseSemaphore() is running at priority 0, the other two threads at priorities 0 and -1, so I can't see how thread priority could cause an issue.
More than that, I don't understand why ReleaseSemaphore() would block under any circumstances. The value of handle is 0x000000ec, which is what it was at the start of the day, so the value of handle hasn't been corrupted, though I guess it is possible that the contents of handle might have been messed up somehow...? Not sure how I would debug that.
Does anyone have any suggestions as to why ReleaseSemaphore() might lock, or what additional things I might poke at in the debugger when the problem occurs to determine what's up?
EDIT: the code is compiled with /Od to avoid any misalignment between the visual debug and the code, this is a screen-shot of what the cppvsdbg window shows for the thread which appears to be blocked on ReleaseSemaphore():
And the correct answer is: no, the Win32 API function ReleaseSemaphore() can never block.
The reason it appeared to be blocking in this case was because, separately, we needed to simulate critical sections on Windows (recalling that this code usually runs in an embedded system on an RTOS, Windows is only for rapid development). To simulate a critical section on Windows we call SuspendThread() (and later ResumeThread()) on all threads except the current thread. A failure was occurring elsewhere in the code while such a simulated critical section was in place, and it so happened that this coincided with the ReleaseSemaphore() call most of the time, making it look as though ReleaseSemaphore() had blocked; it hadn't, the thread just happened to get suspended there.
So we just had to fix the other bug and this apparent problem went away.
I want to suspend a thread in a process and also I want to get all of the threads.
But I googled and didn't find a method to list or change it.
Example, what I mean:
dwm.exe has these threads inside: http://prntscr.com/hru52n (Opened with process explorer).
But I want to make it on cmd (.bat). I really do not know what I should do.
I would be happy if someone helps me.
Thank you!
I want to suspend a thread in a process
Why? It is not advised to do this as there is a good chance you will deadlock the process:
Q: What is the result of suspending a thread in the middle of a
threadsafe operation?
[The] Critical section never gets unlocked if you’re inside it.
Q: What happens if – subsequently – you try to access that same object
(in this case, the console) from another thread?
Deadlock…
Source Why you should never suspend a thread
I have read that SendMessage() should not be used to access UI controls from other threads, but I'm not sure I know why, the only reason that I can think of is since SendMessage() is a blocking call, then it could cause a deadlock in certain situations.
But is this the only reason not to use it?
Edit: This article talks about the reasons not to use SendMessage() but I don't find it to be very clear (it is intended for .NET).
It is best to keep in mind that the odds that you will write correct code are not very good. And the generic advice is don't do it! It is never necessary, the UI thread of a GUI program in Windows was entirely structured to make it simple to allow code that runs on another thread or inside a process affect the UI of the program. The point of the message loop, the universal solution to the producer-consumer problem. PostMessage() is your weapon to take advantage of it.
Before you forge ahead anyway, start by thinking about a simple problem that's very hard to solve when you use SendMessage. How do you close a window safely and correctly?
Given is that the exact moment in time that you need to close the window is entirely unpredictable and completely out of sync with the execution of your worker thread. It is the user that closes it, or asks the UI thread to terminate, you need to make sure that the thread has exited and stops calling SendMessage before you can actually close the window.
The intuitive way to do this is to signal an event in your WM_CLOSE message handler, asking the thread to stop. And wait for it to complete, then the window can close. Intuitive, but it does not work, it will deadlock your program. Sometimes, not always, very hard to debug. Goes wrong when the thread cannot check the event because it is stuck in the SendMessage call. Which cannot complete since the UI thread is waiting for the thread to exit. The worker thread cannot continue and the UI thread cannot continue. A "deadly embrace", your program will hang and needs to be killed forcibly. Deadlock is a standard threading bug.
You'll shout, "I'll use SendMessageTimeout!" But what do you pass for the uTimeout argument and how do you interpret an ERROR_TIMEOUT error? It is pretty common for a UI thread to go catatonic for a while, surely you've seen the "ghost window" before, the one that shows 'Not Responding` in the title bar. So an ERROR_TIMEOUT does not reliably indicate that the UI thread is trying to shut down unless you make uTimeout very large. At least 10 seconds. That kinda works, getting the occasional 10 second hang at exit is however not very pretty.
Solve this kind of problem for all the messages, not just WM_CLOSE. WM_PAINT ought to be next, another one that's very, very hard to solve cleanly. Your worker thread asks to update the display a millisecond before the UI thread calls EndPaint(). And thus never displays the update, it simply gets lost. A threading race, another standard threading bug.
The third classic threading bug is a fire-hose problem. Happens when your worker thread produces results faster than the UI thread can handle them. Very common, UI updates are pretty expensive. Easy to detect, very hard to solve and unpredictable when it occurs. Easy to detect because your UI will freeze, the UI thread burns 100% core trying to keep up with the message rate. It doesn't get around to its low-priority tasks anymore. Like painting. Goes wrong both when you use SendMessage or PostMessage. In the latter case you'll fill the message queue up to capacity. It starts failing after it contains 10000 unprocessed messages.
Long story short, yes, SendMessage() is thread-safe. But thread-safety is not a transitive property, it doesn't automatically make your own code thread-safe. You still suffer from all the things that can go wrong when you use threads. Deadlocks, races, fire-hosing. Fear the threading beast.
my understanding about debugging process and debuggers is that when a breakpoint gets hit, all other threads gets frozen. However one of my colleague said that this option is configurable meaning that somewhere in Visual Studio options you can configure that other threads (where there is no breakpoint) continue to work as normal although the thread with breakpoint get frozen. I couldn't find any such settings in visual studio plus my colleague does not remember where he saw that setting although he seem pretty confident that this option exists.
Can someone confirm if its even possible to have other threads running while one thread gets frozen due to breakpoint? Also if there is such a setting, please let me know where to find it.
The debugger always freezes all threads when a breakpoint hits. You have however do have control over what happens to threads when you press F5 to continue execution. You can use the Freeze toolbar button available in the Debug + Windows + Threads debugger window to prevent a thread from continuing when you press F5. Use the Thaw button to re-enable it.
I'm not familiar with VS, but I know gdb support non-stop mode since version 7.10, so I think it is possible to do like this with VS.
Here is the summary: "For some multi-threaded targets, GDB supports an optional mode of operation in which you can examine stopped program threads in the debugger while other threads continue to execute freely. This minimizes intrusion when debugging live systems, such as programs where some threads have real-time constraints or must continue to respond to external events. This is referred to as non-stop mode."
You can search 'non-stop gdb' for more details.
I don't know if this is possible but frankly if it is, it shouldn't be. Yes it is theoretically possible to break one thread while the others keep running, but keep in mind that with this there is the potential that one of the running threads will try to interact with the frozen thread. this causes all kinds of problems with your current frozen thread. I suspect the debugger was designed with this in mind, so there isn't a setting that allows this. If someone else knows differently please let me know because i find myself curious as well
I have two versions of a minimal web server.
Both execute an infinite loop that receives incoming requests and creates a thread to service each request.
One version simply starts executing that infinite loop.
The other version creates a special thread to execute the infinite loop, and the main program then drops into a standard Windows GetMessage/DispatchMessage loop.
Neither version has a GUI or a console window, they both simply run invisibly, and there's no mechanism coded to make the programs quit (ie, deliberately exit any of their loops).
Any guesses as to why one version uses the extra thread plus GetMessage/DispatchMessage?
It could be habit, based on the habits of the developers of the respective versions. Someone more accustomed to GUI coding might be more likely to add the GetMessage/DispatchMessage code. They may have started with a standard template and adjusted to create the specific project.
Or it could be deliberate -- maybe someone anticipated adding a GUI or some housekeeping tasks in the main thread. Or maybe a watchdog mechanism, where if the infinite loop were to crash (due to an uncaught exception, for instance) the main thread would automatically restart the loop.
I could be way off base, but the question does ask for guesses.