- timed_mutex -- but it acquires the lock - 7 Updates
| David Brown <david.brown@hesbynett.no>: Feb 09 08:25PM +0100 On 09/02/2023 17:34, Frederick Virchanza Gotham wrote: > I could overload 'operator new' and maintain a list of memory > allocations made by "std::this_thread::get_id()". So then when I kill > the thread, I can free the thread's memory. That is not sufficient. When you are killing a thread from the outside, it could be killed at any time. That can include while it is in the middle of an allocation, which may leave the various memory-tracking structures in an inconsistent state. The same applies to all kinds of resources and data structures. The OS will clear up most resources if a process is killed. But if you just kill a thread, you have no way to be sure of re-establishing consistency and a working process. You can get some level of assurance by implementing your own memory management system (at lot more than just overriding new), and other resource tracking - but with all the effort involved, and the overheads, you would be far better off using multiple processes instead of multiple threads. Note that no matter how fantastic your test procedures are, you will probably not find inconsistency bugs in testing. But they can still happen - traditionally, they occur after you have deployed thousands of systems or when you are demonstrating the program for your biggest potential customer. Testing can only ever prove the /existence/ of bugs, never their /absence/ - for that, you need to design the software so that they can't happen. Basically, you are trying to do your robustness here at the wrong level. Threads live and die together. If you need a "watchdog" system to monitor and kill a misbehaving task, kill the process, not a thread. |
| scott@slp53.sl.home (Scott Lurndal): Feb 09 07:39PM >middle of an allocation, which may leave the various memory-tracking >structures in an inconsistent state. The same applies to all kinds of >resources and data structures. Particularly malloc/free and struct FILE (and the corresponding mutex in libc used for thread safe access to struct FILE or the heap allocator won't use Frederick's new soi disant killable mutex). In the datacenters I've visited, they use a watchdog process that detects unexpected inactivity[*] from a server process and kills then restarts the entire server process when the watchdog fires. [*] A ping via a pipe, updated timestamp on disk file, inbound UDP packet, updated field in mmap(MAP_SHARED) or shmat() region, etc. |
| Paavo Helde <eesnimi@osa.pri.ee>: Feb 09 11:24PM +0200 09.02.2023 18:34 Frederick Virchanza Gotham kirjutas: >> - any dynamically allocated memory which was going to be released by >> this thread, is leaked. > I could overload 'operator new' and maintain a list of memory allocations made by "std::this_thread::get_id()". So then when I kill the thread, I can free the thread's memory. You sure have lots of free time for doing meaningless things. But hey, that's why we call them hobbies, right? >> bothered to unlock) remain locked and cannot be unlocked, potentially >> causing further deadlocks. > There's less than 5 locks in the entire program so this won't be difficult to make sure of. I got an impression you proposed your timed_mutex as an universal solution (to some not so clear problems), why else would you advertize it in some public space? Note htat other people might have more than 5 locks in their programs. > I think all of these perils you've mentioned are better than the application just locking up, and MS-Windows showing a progress bar saying "We're contacting Microsoft to tell them this program crashed". Why would you think that? Has Microsoft called you back and reprimanded you? Besides, I believe pthread_kill() does not even compile on Windows, does it? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 09 02:08PM -0800 On 2/9/2023 1:24 PM, Paavo Helde wrote: > you? > Besides, I believe pthread_kill() does not even compile on Windows, does > it? Actually... Iirc, pthreads-win32 has a special kernel hack to do async thread cancellation: https://sourceware.org/pthreads-win32/ God its been ages since I have used that library! Actually, it is pretty damn good! |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 09 02:17PM -0800 On 2/8/2023 11:14 PM, Paavo Helde wrote: > BTW, having a program locked up is perfect, because then you can attach > a debugger, study the thread backtraces and can figure out the bug > easily. Indeed! Well, perhaps not "easy", so to speak. For instance, I found and had to debug a full blown nightmare deadlock in some multi-threaded code I was asked to consult on, many moons ago. They told me it might run for days before the deadlock occurred. The funny part is that I found it during night of stress testing certain parts of the code. It would only deadlock when a certain chain of events would occur, in a specific order... It was a nightmare!. It had to do with recursive locking... YIKES! I had to pause threads at certain points. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 09 03:07PM -0800 On 2/9/2023 1:24 PM, Paavo Helde wrote: >> the thread, I can free the thread's memory. > You sure have lots of free time for doing meaningless things. But hey, > that's why we call them hobbies, right? [...] He should use some of that free time to model his sync scheme in Relacy: https://www.1024cores.net/home/relacy-race-detector |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 09 03:10PM -0800 On 2/9/2023 2:02 AM, Frederick Virchanza Gotham wrote: >> If I write code for a worker thread that never ever ever should take more than 5 seconds to do its job, >> then killing it at 10 seconds, discarding its data and releasing its locks is better than allowing it to keep >> the lock and keep the entire program frozen. [...] Now, are you trying to deal with real time sync? Look up wait-free sync. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment