- Tricky ... - 11 Updates
- rational numbers - 1 Update
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 30 03:33AM +0200 Am 29.09.2021 um 21:05 schrieb Chris M. Thomasson: >>> Yeah. Damn. She does not seem to know a whole lot about memory barriers, >> I use them a lot and correctly. > A wait on a semaphore does not need release semantics. ... It needs because I could have modiefied data before releasing the lock I'm waiting for just at the same time. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 29 06:43PM -0700 On 9/29/2021 6:33 PM, Bonita Montero wrote: >> A wait on a semaphore does not need release semantics. ... > It needs because I could have modiefied data before releasing the > lock I'm waiting for just at the same time. So, it needs acquire release, right? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 29 07:47PM -0700 On 9/29/2021 6:33 PM, Bonita Montero wrote: >> A wait on a semaphore does not need release semantics. ... > It needs because I could have modiefied data before releasing the > lock I'm waiting for just at the same time. Have you posted all of your code for dual_monitor? Or just dual_monitor::wait? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 29 09:57PM -0700 On 9/28/2021 3:05 AM, Bonita Montero wrote: > With what I do the reacquisition is done by the side that unlocks the > mutex. It simply keeps the locked-flag while unlocking and sets the > visitor-event. Where are your example use cases for dual_monitor? I cannot find all of the code for dual_monitor anyway. So, its difficult for me to port to a simulator and use... Just make a new thread, with an example program that uses dual_monitor. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 30 08:16AM +0200 Am 30.09.2021 um 06:57 schrieb Chris M. Thomasson: >> mutex. It simply keeps the locked-flag while unlocking and sets the >> visitor-event. > Where are your example use cases for dual_monitor? ... It's usable when two threads communicate bidirectional. |
| David Brown <david.brown@hesbynett.no>: Sep 30 09:10AM +0200 On 30/09/2021 03:33, Bonita Montero wrote: >> A wait on a semaphore does not need release semantics. ... > It needs because I could have modiefied data before releasing the > lock I'm waiting for just at the same time. If you release a lock, you need release semantics. If you acquire a lock, you need acquire semantics. There is a lot of fiddly stuff in getting memory barriers and synchronisation right - and a lot of /really/ tough stuff in getting it right and optimally efficient on big processors. But "acquire" and "release" semantics are helpfully named! |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 30 01:19AM -0700 On 9/29/2021 11:16 PM, Bonita Montero wrote: >>> visitor-event. >> Where are your example use cases for dual_monitor? ... > It's usable when two threads communicate bidirectional. That's a bit vague. One can create highly efficient bidirectional communication between two threads using two wait-free single-producer/single-consumer queues without using any atomic RMW's, just atomic loads, stores, and some some cleverly placed membars. Now, if one needs to be able to wait on them, well that's a different story. This makes me think about eventcounts; I have plenty of experience with those. God I am getting older. Actually, I am wondering if you happen to be familiar with the good ol' two lock queue? I first saw it decades ago: https://www.cs.rochester.edu/~scott/papers/1996_PODC_queues.pdf A classic! The queues in that paper are well known in lock-free circles... Beware... There are subtle memory lifetime issues that can occur in the lock-free version. Basically, the same horror show that can occur in a lock-free stack. Its not just ABA, its making sure that the memory is valid for a certain operation. Iirc, Windows does something funky with SEH to get this to work in their SList API. ;^) |
| HorseyWorsey@the_stables.com: Sep 30 09:35AM On Wed, 29 Sep 2021 12:05:24 -0700 >>> assume her code is flawed and leave her with it. >> She is clever, but newb. Forgive her for that. >She is clever. Clever in a small area. She seems to have limited knowledge of development and OS methodologies that arn't commonly used in Windows however. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 30 12:39PM +0200 > communication between two threads using two wait-free > single-producer/single-consumer queues without using any atomic RMW's, > just atomic loads, stores, and some some cleverly placed membars. When you use wait-free or lock-free algorithms and there's no data you have to poll. That makes wait-free and lock-free algorithms out of the question. The only lock-free algorihm which ware practicable are lock-free stacks. You can use them for pooling objects or to give back items to a thread which has allocated the items so that ther's no need for a common lock - all modern memory-allocators give back blocks freed bei foreign threads to the thread to whose pool the blocks belongs. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 30 01:00PM -0700 On 9/29/2021 12:09 PM, Chris M. Thomasson wrote: > [...] > Have you posted the whole dual_monitor code? If you did, I missed it. > Sorry. In the mean time, I am working on another fractal set to music. Like these I did last year: https://youtu.be/DSiWvF5QOiI https://youtu.be/QFPSYsYUKBA |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 30 01:20PM -0700 On 9/30/2021 3:39 AM, Bonita Montero wrote: >> just atomic loads, stores, and some some cleverly placed membars. > When you use wait-free or lock-free algorithms and there's no data > you have to poll. Why? [...] |
| Juha Nieminen <nospam@thanks.invalid>: Sep 30 04:46AM > I have nothing against operator<<, it just tends to be slow if > implemented as taught in the books. I believe it was you who stressed > the importance of efficiency in C++. The thing is that with overloading operator<< (or any other similar solution where you have direct access to the stream object) you can choose how to implement the writing. In a scenario where every custom type is forced to implement some kind of "tostring()" function for output you have no choice, even if outputting in some other way would be more efficient, convenient, or even necessary. In fact, it would be better if that "tostring()" would instead be something like "write_to_stream()" which gets the stream object. That way the custom type can choose how it will write to that stream. If it wants to create a string first, it can. But it can also choose to do something else. Which, incidentally, is exactly what overloading operator<< does. My original objection was to the objection that using << is bad, and there are better ways. I was asking what exactly is this "better way". And I do not consider everything having a "tostring()" method to be better. |
| 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