- Thread-safe initialization of static objects - 25 Updates
| Richard Damon <Richard@Damon-Family.org>: Sep 24 08:04AM -0400 On 9/24/23 7:34 AM, Bonita Montero wrote: >> believing that. > Someone here cited the standard with that. Everything different > like spinning (not applicable in userspace) would be unprofessional. Nope, Try to find it. You are just showing you don't understand what you are talking about. In fact, using a mutex the way you are decribing, because it can fail, in "unprofessional", and more importantly, non-conforming. Demanding that specification change because YOU don't see how to meet them is very much "unprofessional" |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 02:10PM +0200 Am 24.09.2023 um 14:01 schrieb Richard Damon: > But it shouldn't NEED to, since the operation can be done without the > possibility of error. That isn't guaranteed for any platform. > And, for non-local initialization, it CAN'T. Non-local initializations are done before main() or before the shared object initialization returns and therefore they don't need any synchronization. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 02:13PM +0200 Am 24.09.2023 um 14:04 schrieb Richard Damon: > In fact, using a mutex the way you are decribing, because it can > fail, in "unprofessional", and more importantly, non-conforming. Yielding is unacceptable and the only second solution that sleeps, as the standard mandates. I don't understand what would be the problem to have a system_error on a synchronization failure with static initialization. |
| Michael S <already5chosen@yahoo.com>: Sep 24 05:21AM -0700 On Sunday, September 24, 2023 at 3:13:21 PM UTC+3, Bonita Montero wrote: > as the standard mandates. I don't understand what would be the > problem to have a system_error on a synchronization failure with > static initialization. I am not an expert in C++ Standard advocacy, rather close to opposite of, but I can guess. Throwing system_error will create an illusion of possibility of useful recovery where in reality useful recovery is impossible. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 02:35PM +0200 Am 24.09.2023 um 14:21 schrieb Michael S: > opposite of, but I can guess. Throwing system_error will create > an illusion of possibility of useful recovery where in reality > useful recovery is impossible. This depends on the code you write if this is acceptable. Sometimes there's also not a useful recovery when a thread responding to another thread fails to lock a mutex, thereby letting the other thread waiting forever; nevertheless there's a system_error with that. |
| Michael S <already5chosen@yahoo.com>: Sep 24 05:47AM -0700 On Sunday, September 24, 2023 at 3:35:46 PM UTC+3, Bonita Montero wrote: > there's also not a useful recovery when a thread responding to another > thread fails to lock a mutex, thereby letting the other thread waiting > forever; nevertheless there's a system_error with that. I don't say that is what should be done. For me, calling abort() with as intelligible as practical error message is what should be done on hosted implementation. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 02:51PM +0200 Am 24.09.2023 um 14:47 schrieb Michael S: > I don't say that is what should be done. > For me, calling abort() with as intelligible as practical error message is > what should be done on hosted implementation. I _sometimes_ call terminate() on synchronization errors also, f.e. when a threads responds back to a thread which issued a task to this thread to prevent starving the other thread. But with the issuing thread first I don't terminate(). It simply depends on the situation and with static initialization it's the same. |
| Daniel <danielaparker@gmail.com>: Sep 24 05:57AM -0700 On Friday, September 22, 2023 at 6:32:02 PM UTC-4, Richard Damon wrote: > The fact that you are too stupid Perhaps Richard could reflect on the fact that with regard to manners and civility, he's also as stupid as they come. Something to work on. The heavyweights that used to post here never had that problem. Best regards, Daniel |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 24 12:27PM -0400 On 9/24/23 08:04, Richard Damon wrote: > On 9/24/23 7:34 AM, Bonita Montero wrote: ... > in "unprofessional", and more importantly, non-conforming. > Demanding that specification change because YOU don't see how to meet > them is very much "unprofessional" No, it is very professional to complain about specifications that can't be met. What is unprofessional is incorrectly concluding that they cannot be met (especially after having had it explained to you many times). |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Sep 24 12:46PM -0400 Bonita Montero wrote: > cation poblem, i.e. the memory of your object may never be deallocated. > Show me your implementation ! > It's ridiculous because mutex are a cheap resource. Cheap as compared to what? How is a mutex "cheaper" than other synchronization primitives? Also, what exactly mutex operation(s) is/are cheap? Also, what exactly mutex type is cheap? On what platform? A blanket statement is never entirely true or false, nothing can be "ridiculous" because of it. |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Sep 24 12:47PM -0400 Bonita Montero wrote: >> But it shouldn't NEED to, since the operation can be done without the >> possibility of error. > That isn't guaranteed for any platform. Name one platform for which it is not guaranteed and that targets a compliant C++11+ implementation. |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Sep 24 12:53PM -0400 Bonita Montero wrote: >> believing that. > Someone here cited the standard with that. Everything different > like spinning (not applicable in userspace) would be unprofessional. Kernel-level sleeping and waking up is more or less moving an execution context from runlist to a waiting list and back. Why should such an operation be fail-able? |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Sep 24 12:59PM -0400 Chris M. Thomasson wrote: > [...] > I don't think there is a timed wait for a windows critical section. I > know it has a try, but I cannot remember a timed wait... It is not a timed wait controlled by the user. But it waits for some time (specified in the registry) and then fails -- that is its way to *try* to detect a deadlock. Says the doc on EnterCriticalSection: " This function can raise EXCEPTION_POSSIBLE_DEADLOCK, also known as STATUS_POSSIBLE_DEADLOCK, if a wait operation on the critical section times out. The timeout interval is specified by the following registry value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\CriticalSectionTimeout. Do not handle a possible deadlock exception; instead, debug the application. " |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Sep 24 01:00PM -0400 Chris M. Thomasson wrote: >> issue of static C++ initialization). > Iirc, I think a windows critical section might raise an error if its > been waiting for 30 days or something, deadlocked. Exactly, that's what I meant, just cited in the other response. It is, by behavior, a timed recursive mutex but user does not control the time. |
| Kaz Kylheku <864-117-4973@kylheku.com>: Sep 24 05:04PM > atomically update the link pointers of the other nodes at the same > time you update the roots link pointers. And you would have the deallo- > cation poblem, i.e. the memory of your object may never be deallocated. Now you're just throwing together words you don't understand. > Show me your implementation ! E.g. old LinuxThreads in glibc, circa 2000: https://sourceware.org/git/?p=glibc.git;a=blob;f=linuxthreads/spinlock.c;h=5cd772602c8858edd8238e73eefcbf2758935d74;hb=d82e4c7bb231c9e0f835bd46467563ac3b56cebe The low level __pthread_lock and __pthread_unlock functions maintain a queue, using a single-word atomic CAS. There are suspend() and resume() functions for the waiting; they are elsewhere. If you look in restart.h you can see that those operations are defined in two different ways, both of which use signals (not a semaphore per thread). A suspending thread waits for the arrival of a signal, resume is done by sending a signal. That's kind of semaphore-like; and POSIX real-time signals can even queue up, like a counting sem. > It's ridiculous because mutex are a cheap resource. And if such imple- > mentation would be possible the standard shouldn't mandate it since > not every platform has a DCAS. Things can be done in ways you havn't thought about. Atomic operations aren't required to achieve mutual exclusion among processors that share memory. As someone continually insisting on having expertise in concurrency, you must be familiar with the research work of Leslie Lamport? For instance, the paper _A Fast Mutual Exclusion Algorithm_ [1985]. Abstract: "A new solution to the mutual exclusion problem is presented that, in the absence of contention, requires only seven memory accesses. It assumes atomic reads and atomic writes to shared registers." Snipeet from Introduction which gives a clue as to the motivation: "Recently, there has arisen interest in building shared-memory multiprocessor computers by connecting standard processors and memories, with as little modification to the hardware as possible. Because ordinary sequential processors and memories do not have atomic test-and-set operations, it is worth investigating whether shared-memory mutual exclusion algorithms are a practical alternative." -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted. |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Sep 24 01:10PM -0400 Bonita Montero wrote: >> standard says no such thing. > constexpr mutex() noexcept; > https://en.cppreference.com/w/cpp/thread/mutex/mutex so? everyone has been telling you initialization of simple mutices does not fail. After few hundred posts, you decided to agree? >> in user space (like POSIX mutex on linux is created) > If the mutex' constructor is noexcept the kernel-part for the slow > path has to be initialized delayed while locking. You can rename your favorite part of locking "initialization" for your internal use; but it is advisable to use standard terms if you write for others. Regardless of how it is called, no part of simple mutex lock has to be fail-able. > Rest unread. yet another broken promise |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 24 11:34AM -0700 On 9/24/2023 1:08 AM, Bonita Montero wrote: > It's ridiculous because mutex are a cheap resource. And if such imple- > mentation would be possible the standard shouldn't mandate it since > not every platform has a DCAS. Pardon my French, but that is a rather horrible idea, for several reasons... |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 24 11:36AM -0700 On 9/24/2023 1:09 AM, Bonita Montero wrote: >> anyway? ... > Call it std::mutex or whatever. It is mandated that contenders > are sleeping - that's not possible without sth. else than a mutex. You lost me here. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 24 11:41AM -0700 On 9/24/2023 2:50 AM, Michael S wrote: > waking just fine and initialization of different objects proceeds > simultaneously just fine. And it does not use mutex for that. > It uses SleepEx() for wait and QueueUserApc() for wakeup. Why? APC's open up a big can of worms. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 24 11:42AM -0700 On 9/24/2023 4:55 AM, Bonita Montero wrote: > than necessary under load conditions or if not, may actually spin > and consume unecessary power. So a semaphore is the only solution > that makes sense. You are all over the place. Sigh. Sorry, Bonita but you are fired from the team. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 24 11:43AM -0700 On 9/24/2023 10:00 AM, Pavel wrote: >> been waiting for 30 days or something, deadlocked. > Exactly, that's what I meant, just cited in the other response. It is, > by behavior, a timed recursive mutex but user does not control the time. Well, in that sense, okay. I see what you are getting at. :^) |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 24 11:45AM -0700 On 9/24/2023 9:59 AM, Pavel wrote: > Manager\CriticalSectionTimeout. Do not handle a possible deadlock > exception; instead, debug the application. > " Thanks for your clarification. No problem. :^) |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 24 11:49AM -0700 On 9/24/2023 11:41 AM, Chris M. Thomasson wrote: >> simultaneously just fine. And it does not use mutex for that. >> It uses SleepEx() for wait and QueueUserApc() for wakeup. > Why? APC's open up a big can of worms. Oh shit. I am starting to remember some nightmare code I had to debug many moon ago that used async cancellation in POSIX threads. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 24 11:50AM -0700 On 9/24/2023 5:51 AM, Bonita Montero wrote: > to prevent starving the other thread. But with the issuing thread first > I don't terminate(). It simply depends on the situation and with static > initialization it's the same. Oh my god. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 24 12:08PM -0700 On 9/24/2023 11:49 AM, Chris M. Thomasson wrote: >>> practicality rather than out of necessity. I am pretty sure that >>> with enough effort I can device a variant that achieves the same >>> with CaS. Now, I am recalling async safe sync objects that must be used in a signal handler for some reason. |
| 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