- timed_mutex -- but it acquires the lock - 7 Updates
- Found a use case for `const` by value return, a shared queue - 2 Updates
- lvalue assignment difference between C and C++ - 2 Updates
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 07 04:06PM -0800 On 2/7/2023 3:01 PM, Scott Lurndal wrote: >> are for inter process sync. > The owning thread could exit (or be cancelled) without releasing the mutex > and without killing the process. Touche. Yeah, well, I was thinking of died as in seg fault without handling it. I have never had a use for the following: https://linux.die.net/man/3/pthread_kill Never had any use for pthread_cancel. I have only used robust mutexes for inter process communication. Using them for anything else is really strange to me. Threads just up and dying in a process is NOT kosher, in my humble opinion. However, a process dying is a different story. > from being partially updated and hence buggy when the robust mutex was released. > If the dead thread had been in the middle of a linked list update, for > example, the list could end up with a loop or sans a bunch of entries. Yup. Iirc, I had to do some tricky rollback operations back when I had to use them. A process dying had to be handled. I never had to rely on robust mutexes for intra process sync, only inter process. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 07 04:08PM -0800 On 2/7/2023 1:25 AM, Frederick Virchanza Gotham wrote: > Since C++11, we already have "std::timed_mutex". It will try to acquire the lock for N seconds and fail, and you can handle the failure. > I want to make another kind of timed mutex, called something like "std::timed_rescuable_mutex", but the difference will be that when you invoke "try_lock_for", it will wait for N seconds, and then if the mutex is still locked, it will kill the thread that locked it, and then unlock the mutex. [...] My god, that is a bad idea. |
| Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Feb 08 10:37AM -0800 On Wednesday, February 8, 2023 at 12:08:20 AM UTC, Chris M. Thomasson wrote: > > I want to make another kind of timed mutex, called something like "std::timed_rescuable_mutex", but the difference will be that when you invoke "try_lock_for", it will wait for N seconds, and then if the mutex is still locked, it will kill the thread that locked it, and then unlock the mutex. > [...] > My god, that is a bad idea. is it worse than the entire program locking up because one thread has frozen? I'm proposing a solution that is less bad than the problem. Better to kill a frozen thread and discard its work, than have the entire program lock up. |
| Paavo Helde <eesnimi@osa.pri.ee>: Feb 08 08:52PM +0200 08.02.2023 20:37 Frederick Virchanza Gotham kirjutas: >> My god, that is a bad idea. > is it worse than the entire program locking up because one thread has frozen? > I'm proposing a solution that is less bad than the problem. Better to kill a frozen thread and discard its work, than have the entire program lock up. If your program has a bug so that a thread gets stuck, then find and fix the bug. Do not try to hide it or to work around it, it will just cause endless pain and in the end you still need to fix the bug. Do not forget to create an automated test case to ensure the bug is gone and does not come back. Ah, I know you won't listen to me anyway, but maybe others do. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 08 12:36PM -0800 On 2/8/2023 10:37 AM, Frederick Virchanza Gotham wrote: >> [...] >> My god, that is a bad idea. > is it worse than the entire program locking up because one thread has frozen? When you wrote that a thread can wind up getting itself into an infinite loop, what exactly do you mean? A loop that is just running burning up the CPU doing nothing? for (;;) { } ? > I'm proposing a solution that is less bad than the problem. Better to kill a frozen thread and discard its work, than have the entire program lock up. Why are your threads getting "frozen" and how does it end up locking up the entire program? Don't tell me you are holding a mutex while the thread blocks on io... That is a "classic" bad design issue. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 08 12:37PM -0800 On 2/8/2023 10:52 AM, Paavo Helde wrote: > If your program has a bug so that a thread gets stuck, then find and fix > the bug. Do not try to hide it or to work around it, it will just cause > endless pain and in the end you still need to fix the bug. Big time. > Do not forget to create an automated test case to ensure the bug is gone > and does not come back. Taking the time to model a synchronization scheme in Relacy is a good thing: https://github.com/dvyukov/relacy |
| Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>: Feb 08 03:14PM -0800 On Wednesday, February 8, 2023 at 6:52:43 PM UTC, Paavo Helde wrote: > If your program has a bug so that a thread gets stuck, then find and fix > the bug. Do not try to hide it or to work around it, it will just cause > endless pain and in the end you still need to fix the bug. There hasn't been a bug reported yet. > Do not forget to create an automated test case to ensure the bug is gone > and does not come back. I'm trying to make my program more robust and resilient, and so even though it seems to work fine in the handful of hours I test it, I don't assume that it always works perfectly in the dozens of hours that other people use it. I haven't had a thread freeze up on me yet......... but if it does happen in the future, I'd like to be ready for it. Of course thought I might make my program *less* reliable by adding in precautionary stuff. First I'll write the code for 'timeout_mutex' and see how it looks. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Feb 08 04:49PM > These go way back - "The Design and Evolution of C++" describes them. My > copy of "The C++ Programming Language" and the first version of the C++ > standard have unfortunately both gone missing, I have the second edition of that book (1991) and they are not mentioned. I don't recall when they came along but, as Keith as said, there were there by the first C++ ISO standard (1998). The names are a bit confusing because not_eq and and_eq share an ending but one is about equality and the other about assignment. -- Ben. |
| red floyd <no.spam.here@its.invalid>: Feb 08 11:11AM -0800 On 2/8/2023 8:49 AM, Ben Bacarisse wrote: > The names are a bit confusing because not_eq and and_eq share an ending > but one is about equality and the other about assignment. I think they chose those expansions because they match how people would say those operators when reading code out loud. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Feb 08 02:52AM > On Mon, 06 Feb 2023 13:03:11 -0800 > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: <cut> >>has to interact with the symbol table. (Historically, this is because >>typedefs were introduced relatively late in the evolution of C.) > Could it not cheat and simply treat a typedef as a kind of macro? Keith has mentioned the scope issue, but there are other problems with a simple textual substitution. For example, after typedef int *T; the declaration const T x; gives x a const-qualified type (i.e. you can't assign to x). A simple substitution of "T" for "int *" does not have the same effect at all. -- Ben. |
| Muttley@dastardlyhq.com: Feb 08 09:23AM On Tue, 07 Feb 2023 11:08:23 -0800 > } > // int Integer = 20; // would be a syntax error >} Do you know I never knew you could do that with C. I thought it was C++ only. Learnt something new today! |
| 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