- Thread-safe initialization of static objects - 20 Updates
- How to concat two constexpr c-string? - 4 Updates
- Where can I buy Agaric Amanita muscaria polkaDot mushroom - 1 Update
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 23 07:00PM -0700 On 9/23/2023 2:58 PM, Pavel wrote: > On Windows, critical section is essentially a recursive > deadlock-detecting (timed) mutex so it is relatively expensive and can > fail. [...] 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... |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 23 07:03PM -0700 On 9/23/2023 2:58 PM, Pavel wrote: > -- which is all one needs for static initialization (coincidentally, on > Win32 specifically InitOnceInitialize does not fail either but this is > irrelevant to the 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. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 04:10AM +0200 Am 23.09.2023 um 23:58 schrieb Pavel: > standard says that recursive_mutex, recursive_timed_mutex and any of the > shared mutices can throw system_error). About std::mutex the standard > says no such thing. constexpr mutex() noexcept; https://en.cppreference.com/w/cpp/thread/mutex/mutex > Wrong. a mutex can be created during static initialization entirely > 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. Rest unread. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 23 07:19PM -0700 On 9/23/2023 7:10 PM, Bonita Montero wrote: >> 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. Huh? > Rest unread. Figured. |
| Kaz Kylheku <864-117-4973@kylheku.com>: Sep 24 02:22AM > en entry in the wait queue of the semaphore. This may not apply for > all operating systems, but this is a theoretical possibility the > standard shout honor. The thing is, mutexes don't require a kernel object per. A possible design is that each *thread* has a wait semaphore. If a thread is created, it has a semaphore;the resource check can be done at thread creation time. If we cannot create that important semaphore, the thread doesn't get created; thread creation fails. When a thread waits on mutex, it puts itself into the mutex's wait queue, and then waits on its own semaphore. It uses that semaphore for all mutexes. When the mutex is unlocked, one (or maybe more) threads waiting on it are dequeued and woken by signaling their individual semaphore. These semaphores can be hidden under operations suspend() and resume(thread). suspend() finds the thread's self structure, and blocks on self->suspend_sem. resume(thread) signals the thread->suspend_sem. Roughly speaking. You need a lower level locking mechanism to do the queuing. Inside a kernel, you'd never bother with a semaphore per lock, because you just put the thread into a wait queue, change it to a blocked state, and call the scheduler. Those mechanisms could be used to *build* a semaphore. Or barrier, (The semaphore-per-thread in user space simulates that: using suspend() and resume(thread) is like scheduling. suspend() deschedules this thread; resume(thread) chooses a thread to be runnable.) condition variable, etc. -- 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. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 23 07:59PM -0700 On 9/23/2023 7:22 PM, Kaz Kylheku wrote: > and resume(thread) is like scheduling. suspend() deschedules this > thread; resume(thread) chooses a thread to be runnable.) > condition variable, etc. That's about it. The only problem wrt emulating it in user space is that it basically takes the scheduling ability away from the OS. struct per_thread { per_thread* m_next; os_semaphore m_sema; }; So, to wake a thread on the unlock of a mutex or something, wrt the wait queue it would just pop a node and post to its semaphore. It did not "necessarily" have to search itself for a specific thread... We can use some indirection: struct per_thread_node { per_thread_wait_node* m_next; per_thread* m_thread; }; And use per_thread_node instead of using per_thread directly to link them into a wait queue. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 23 08:05PM -0700 On 9/23/2023 8:23 AM, Bonita Montero wrote: > a semaphore may fail under rare conditions, but what happens then > needs to be clearly defined for me. std::mutex has defined means > to handle that, static initialization not. Why do you think that static initialization must use a std::mutex anyway? Why do you think that std::mutex must use some delayed kernel resource initialization? Strange. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 23 08:08PM -0700 On 9/23/2023 7:59 PM, Chris M. Thomasson wrote: > struct per_thread_node > { > per_thread_wait_node* m_next; ^^^^^^^^^^^^^^^^^^^^ That should be: per_thread_node* m_next; > per_thread* m_thread; > }; Damn typos! |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 10:08AM +0200 Am 24.09.2023 um 04:22 schrieb Kaz Kylheku: > A possible design is that each *thread* has a wait semaphore. You'd have to register the binary semaphore and register as a waiter in one atomic step. You could do that with a DCAS'd ring, but you coudn't 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. Show me your implementation ! 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. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 10:09AM +0200 Am 24.09.2023 um 05:05 schrieb Chris M. Thomasson: > Why do you think that static initialization must use a std::mutex > anyway? ... Call it std::mutex or whatever. It is mandated that contenders are sleeping - that's not possible without sth. else than a mutex. |
| Michael S <already5chosen@yahoo.com>: Sep 24 02:50AM -0700 On Sunday, September 24, 2023 at 11:09:31 AM UTC+3, 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. Few dozens posts above I demonstrated an implementation for pre-Vista Windows where contenders are sleeping just fine and 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. It uses one global mutex (in form of critical section) for a short while for metadata updates, but that's done for simplicity and 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. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 12:05PM +0200 Am 24.09.2023 um 11:50 schrieb Michael S: > ...And it does not use mutex for that. > It uses SleepEx() for wait and QueueUserApc() for wakeup. That's also a kind of semaphore. |
| Richard Damon <Richard@Damon-Family.org>: Sep 24 07:15AM -0400 On 9/24/23 4: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. So, you still think that the Standard should allow a very common operation to fail in ways that the program can not handle it when another method exists to do the operation exists that has no opportunity for failure. You just don't understand programming. Something that is marginally faster, but introduces chance of failure, is NOT an improvement or valid optimization. The fact that YOU don't understand how to do a standard operation, doesn't mean it isn't a good way to do it. |
| Michael S <already5chosen@yahoo.com>: Sep 24 04:18AM -0700 On Sunday, September 24, 2023 at 11:09:31 AM UTC+3, Bonita Montero wrote: > > Why do you think that static initialization must use a std::mutex > > anyway? ... > It is mandated that contenders are sleeping Really? I never had read the Standard, but somehow have troubles believing that. Would expect that it's matter of quality of implementations rather than of mandate. Even more so - requirement to wake up timely if sleeping indeed happened. It's expected from good implementation, but I can't believe that it's mandated by Standard. |
| Richard Damon <Richard@Damon-Family.org>: Sep 24 07:18AM -0400 On 9/24/23 4: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. Where is it mandated that they "Sleep"? What is mandated is that initialization occur just once and no code can access the object (if properly accessed) before its initialization. I think you don't understand the meaning of the Standard. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 01:33PM +0200 Am 24.09.2023 um 13:15 schrieb Richard Damon: > operation to fail in ways that the program can not handle it when > another method exists to do the operation exists that has no > opportunity for failure. The program could easily handle that by catching a system_error. There's nothing different from that if the constructor itself throws an error. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 01:34PM +0200 Am 24.09.2023 um 13:18 schrieb Michael S: > Really? I never had read the Standard, but somehow have troubles > believing that. Someone here cited the standard with that. Everything different like spinning (not applicable in userspace) would be unprofessional. |
| Michael S <already5chosen@yahoo.com>: Sep 24 04:50AM -0700 On Sunday, September 24, 2023 at 2:35:09 PM UTC+3, Bonita Montero wrote: > > believing that. > Someone here cited the standard with that. Everything different > like spinning (not applicable in userspace) would be unprofessional. Can I conclude that you also didn't read the Standard? As to what is professional and what not, it's matter of opinion and circumstances. After all, we are talking about rare situation during use of obscure language feature. On Linux or post-XP Windows it is easy to be both robust and performant. But if platform in question does not provide obvious both robust and performant way of dealing with it, then many people, including myself, would prefer robust solution over performant one. I.e. we will take a solution in which late comers are waiting on done flag ina loop with Sleep(1) over dynamic allocation of kernel object that can theoretically fail. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 01:55PM +0200 Am 24.09.2023 um 13:50 schrieb Michael S: > As to what is professional and what not, it's matter of opinion > and circumstances. ... The implementation can't estimate how long a static initialization takes. If it takes a longer time spinning would be a real problem. Yielding would also be not ok because the contenders may wait longer 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. |
| Richard Damon <Richard@Damon-Family.org>: Sep 24 08:01AM -0400 On 9/24/23 7:33 AM, Bonita Montero wrote: > The program could easily handle that by catching a system_error. > There's nothing different from that if the constructor itself > throws an error. But it shouldn't NEED to, since the operation can be done without the possibility of error. And, for non-local initialization, it CAN'T. |
| JiiPee <kerrttuPoistaTama11@gmail.com>: Sep 24 11:48AM +0300 On 26/08/2023 13:44, Öö Tiib wrote: > You can make std::array compile time as it can be passed. Am I right that in this kind of situationsa std::array is recommended rather than C arrays? |
| JiiPee <kerrttuPoistaTama11@gmail.com>: Sep 24 11:54AM +0300 On 26/08/2023 13:51, Bonita Montero wrote: > constexpr std::string_view > first( concatted, 3 ), > second( concatted + 3, 3 ); ye that view is surely good in this kind of things. I kinda "forgot" to use it, should maybe use it more to become second nature. |
| JiiPee <kerrttuPoistaTama11@gmail.com>: Sep 24 11:55AM +0300 On 26/08/2023 23:04, Alf P. Steinbach wrote: > constexpr auto& k3 = K3; > Easy peasy. :-) > - Alf But isnt it that many recommend not to use define's? |
| David Brown <david.brown@hesbynett.no>: Sep 24 11:55AM +0200 On 24/09/2023 10:48, JiiPee wrote: >> You can make std::array compile time as it can be passed. > Am I right that in this kind of situationsa std::array is recommended > rather than C arrays? When you have a fixed compile-time size for an array, I prefer std::array, as it makes the array a "solid" object. (In C, I wrap the array in a struct.) You can pass it by value, assign it, and so on. You can use it like a container with some of the common container methods and functions, for loops, and that kind of thing. The key disadvantage of std::array is that since the size is part of the type, you can't make a single non-template function that takes arrays of different sizes as parameters. If that is not an issue for a particular use-case, then std::array is often a nicer choice. |
| Ng Lee <ngplbug826@gmail.com>: Sep 23 11:41PM -0700 https://exoticpsychstore.store buy polkadot mushroom chocolate bars, polkadot mushroom chocolate bars for sale online, polka dot bars, magic mushroom belgian chocolate, magic mushroom chocolate bar, magic mushroom chocolate bar for sale, mushroom chocolate bars for sale, mushroom chocolate bars polka dot, polka dot bars, polka dot chocolate mushroom, polka dot chocolates where to buy, polka dot company chocolate, polka dot edibles, polka dot magic belgian chocolate price, polka dot magic mushroom bar, polka dot magic mushroom reviews, polka dot mushroom bar, polka dot mushroom bar review, polka dot mushroom chocolate dc, polka dot mushroom chocolate dosage, polka dot mushroom chocolate near me, polka dot psilocybin bars, polka dot psilocybin chocolate bars, polkadot bar, polkadot chocolates, polkadot magic belgian chocolate, polkadot magic belgian chocolate reviews, polkadot magic mushroom belgian chocolate, polkadot mushroom belgian chocolate, Polkadot Mushroom Chocolate Bars, polkadot h https://exoticpsychstore.store https://exoticpsychstore.store Made with love with Oakland - one of the oldest and safest natural medicines in the world, Health benefits from magic chocolate have been known to reduce stress, depression, stimulate brain cell growth, increase focus and sharpen your senses. The amazing therapeutic effects derived from the Polkadot mushroom chocolate bars depend on the dosage. Each of our polkadot bars have 15 easily breakable pieces and the degree of effects you get from consuming these shrooms chocolate bars will depend o the number of pieces you consume. https://exoticpsychstore.store https://exoticpsychstore.store MICRODOSE (STIMULATE THE MIND) : 1-3 PIECES THERAPEUTIC (MINDFUL AND ELEVATED): 4-9 PIECES GOD MODE (WALLS MAY MELT) : 10-15 PIECES CAUTION: Consume slowly in a safe environment. Do not operate any motor vehicles while using this product. Keep out of reach of children and pets. https://exoticpsychstore.store https://exoticpsychstore.store POLKADOT MUSHROOM CHOCOLATE BARS FOR SALE https://exoticpsychstore.store Polkadot mushroom chocolate bars are meant to help you conquer your fears and brighten your mood. The adventure you embark on with these fantastic mushroom chocolate bars depends on the dosage. The Polkadot Magic Mushroom Belgian milk chocolate is not only delicious but an equivalent of 4 grams of psilocybin-containing mushrooms. Apart from the fantastic trippy effects you get from eating the polka dot mushroom chocolate bars, they are also a great way to microdose magic mushrooms. Microdosing magic mushrooms in the form of consuming mushroom chocolate bars have recently increased in popularity. https://exoticpsychstore.store Furthermore, if you can't stand the smell and "bad taste" of raw magic mushrooms, the Polkadot magic mushroom chocolate bar is a great alternative. https://exoticpsychstore.store Psilocybin - the active ingredient in the polka dot mushroom chocolate bar, polkadot magic belgian chocolate, is known to reduce stress, depression and anxiety. Polkadot bars are also a great way to stimulate brain cell growth, Increase focus and sharpen your senses. https://exoticpsychstore.store Why a chocolate bar with mushrooms and polka dots? |
| 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