| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 04 12:01AM -0700 On 11/1/2023 12:59 PM, Chris M. Thomasson wrote: >> The first replier says the same I said: its a normal mutex. > Huh? The benaphore is a semaphore! So, both of you are totally wrong > here. Think about it... Your theme song? https://youtu.be/FE-hBbBBGBs |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 04 12:19AM -0700 On 11/3/2023 3:13 PM, Chris M. Thomasson wrote: >> this case and loops internally, whereas compare_exchange_weak gives a >> false result after one try. > Strong CAS cannot fail spuriously. Put on your thinking cap. CMPXCHG cannot fail spuriously. However, LL/SC can. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 04 10:13AM +0100 Am 04.11.2023 um 08:19 schrieb Chris M. Thomasson: >>> false result after one try. >> Strong CAS cannot fail spuriously. Put on your thinking cap. > CMPXCHG cannot fail spuriously. However, LL/SC can. Youre telling things I've told above in a different way. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 04 10:15AM +0100 Am 03.11.2023 um 21:56 schrieb Kaz Kylheku: > An atomic counter, featuring a wait when the value is in a certain > range, is known as semaphore. An atomic counter alone isn't sufficient for a semaphore because there's no way to sleep or to be awakened with that. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 04 10:16AM +0100 Am 03.11.2023 um 23:19 schrieb Chris M. Thomasson: >>> ownership and semaphores do not. ... >> Mutexes only have ownership if they're recursive. > WHAT!!! ? ;^o It't the surrounding code that "knows" that it is an owner, not the mutex itself. A non-recurive mutex just knows that it is owned, but not by whom. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 04 10:17AM +0100 Am 03.11.2023 um 23:25 schrieb Chris M. Thomasson: >> that that mutexes usually have no ownership. You can see that with >> the benapohre. > Oh shit. You have dug yourself into a really deep hole here, Bonita. The benaphore does know that it is owned, but not by whom. Its the surrounding code that knows that it owns the mutex. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 04 10:18AM +0100 Am 03.11.2023 um 23:18 schrieb Chris M. Thomasson: > Oh my. A benaphore is basically a userspace semaphore using a kernel > semaphore for slow paths. There isn't sth. like a userspace semaphore since with a sempahore you need support to sleep or to be awakened. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 04 10:19AM +0100 Am 01.11.2023 um 20:59 schrieb Chris M. Thomasson: > Huh? The benaphore is a semaphore! So, both of you are totally wrong > here. Think about it... Google for "benaphore mutex" and you'll find several refernces that a benaphore is a mutex, including the two articles I've referred so far. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 04 10:25AM +0100 Am 03.11.2023 um 23:19 schrieb Chris M. Thomasson: >>> ownership and semaphores do not. ... >> Mutexes only have ownership if they're recursive. > WHAT!!! ? ;^o It's not necessary to record ownership of a specific thread for a non recursive mutex but just _that_ a mutex is ownend, and not by whom. The benaphore can easily locked in one thread and unlocked in another thread, although this usually doesn't happen. It's just the surrounding code that successfully locked a mutex that "knows" it is the owner. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 04 10:29AM +0100 Maybe I missed some header which is implicitly included with me. The code compiles fine with g++, clang++, clang-cl and MSVC on my PC. Am 03.11.2023 um 22:18 schrieb Branimir Maksimovic: |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 04 10:53AM +0100 Am 04.11.2023 um 10:19 schrieb Bonita Montero: > Google for "benaphore mutex" ... Or rather "benaphore mutex -semaphore". |
| scott@slp53.sl.home (Scott Lurndal): Nov 04 03:53PM >>> false result after one try. >> Strong CAS cannot fail spuriously. Put on your thinking cap. >CMPXCHG cannot fail spuriously. However, LL/SC can. LL/SC is not compare and swap. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 04 04:58PM +0100 Am 04.11.2023 um 16:53 schrieb Scott Lurndal: >>> Strong CAS cannot fail spuriously. Put on your thinking cap. >> CMPXCHG cannot fail spuriously. However, LL/SC can. > LL/SC is not compare and swap. Cite where I said sth. opposite. |
| scott@slp53.sl.home (Scott Lurndal): Nov 04 04:03PM >> this case and loops internally, whereas compare_exchange_weak gives a >> false result after one try. >Strong CAS cannot fail spuriously. Put on your thinking cap. BTW - Compare and Swap was invented by an engineer at IBM - CAS is a backronym, the inventors initials are CAS. https://www.garlic.com/~lynn/2004l.html#56 "charlie had come up with compare and swap at the science scenter http://www.garlic.com/~lynn/subtopic.html#545tech based on a lot of work he was doing in fine grain locking (late 60s) ... and tried to get it into 370 architecture. POK architecture owners came back and said it wasn't possible to justify a multiprocessor-specific instruction for the 370 architecture (already having test&set) ... and that to get it justified, it would be necessary to come up with a non-multiprocessor use for the instruction. thus was born the description for multi-threaded application use in non-locked regions .... when running on either multiprocessor or non-multiprocessor machines. this was originally included in the 370 prinicple of operations as programming notes associated with the compare&swap instruction(s). the description has since been expanded and moved to the principles of operation appendix. note that the choice of compare and swap comes from needing a mnemonic that matched charlie's initials (CAS). the mnemonic was slightly changed for inclusion in 370 to CS (compare and swap) and CDS (compare double and swap). the instructions have since been expanded for 64-bit operation and a new "perform locked operation" has since been added. |
| scott@slp53.sl.home (Scott Lurndal): Nov 04 04:05PM >> range, is known as semaphore. >An atomic counter alone isn't sufficient for a semaphore because >there's no way to sleep or to be awakened with that. Sure there is. It's even obvious. |
| David Brown <david.brown@hesbynett.no>: Nov 04 05:22PM +0100 On 03/11/2023 18:08, Bonita Montero wrote: >> Note the sentence "The mutex must be locked by the current thread of >> execution, otherwise, the behavior is undefined." > Maybe, but I'm talking about how mutexes usually work internally. I think, from this thread, it is clear that you have no idea how mutexes are used. I therefore assume you have no idea how they work internally. And I am entirely confident that your idea of "usually" is limited to one single OS. >> does not make a good lock. A main reason for that is that it has no >> concept of ownership. ... > Mutexes also usually have no notion of ownership. I stand corrected. Your idea of "usually" is limited to no OS in existence. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 04 05:35PM +0100 Am 04.11.2023 um 17:22 schrieb David Brown: > I think, from this thread, it is clear that you have no idea how mutexes > are used. ... I use them every day and I've developed my own reader's-writer-lock. > I stand corrected. Your idea of "usually" is limited to no OS in > existence. A non-recurive mutex doensn't need to know which thread is the owner, but just that there's an owner. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 04 05:35PM +0100 Am 04.11.2023 um 17:05 schrieb Scott Lurndal: >> An atomic counter alone isn't sufficient for a semaphore because >> there's no way to sleep or to be awakened with that. > Sure there is. It's even obvious. Not for Kaz. |
| David Brown <david.brown@hesbynett.no>: Nov 04 05:56PM +0100 On 04/11/2023 17:35, Bonita Montero wrote: >> I think, from this thread, it is clear that you have no idea how >> mutexes are used. ... > I use them every day and I've developed my own reader's-writer-lock. Do you do all your work relying on luck? >> existence. > A non-recurive mutex doensn't need to know which thread is the > owner, but just that there's an owner. No, it needs to know the owner - because only the owner is allowed to release the lock. I suppose you could make a half-arsed mutex implementation that relies on programmers never making mistakes, and just let the nasal demons fly when people like you can't read and follow specifications. And even if you have such a poor mutex implementation, conceptually there is always an owner when the lock is taken - that's the point of the thing. |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 04 06:18PM +0100 Am 04.11.2023 um 17:56 schrieb David Brown: > No, it needs to know the owner - because only the owner is allowed to > release the lock. This is a superfluous check that does not determine function. > I suppose you could make a half-arsed mutex implementation that relies > on programmers never making mistakes, and just let the nasal demons fly > when people like you can't read and follow specifications. It may be possible to release a mutex from another thread, but as no one does this this check doesn't make sense. That that much unlikely that that happens that it doesn't make sense as a debugging aid, even more in C++, where you can't forget unlocking inside the same thread if you use a unique_lock<> or lock_guard<>. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 04 11:44AM -0700 On 11/4/2023 8:53 AM, Scott Lurndal wrote: >> CMPXCHG cannot fail spuriously. However, LL/SC can. > LL/SC is not compare and swap. LL/SC can be used to implement a weak CAS. Also, wrt the algorithm, it can be used to implement a strong CAS. CMPXCHG over on intel cannot be used to implement a weak CAS. |
| Kaz Kylheku <864-117-4973@kylheku.com>: Nov 04 06:44PM >> range, is known as semaphore. > An atomic counter alone isn't sufficient for a semaphore because > there's no way to sleep or to be awakened with that. You're not successfully making it appear as if I said that. -- 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>: Nov 04 11:45AM -0700 On 11/4/2023 9:03 AM, Scott Lurndal wrote: > for inclusion in 370 to CS (compare and swap) and CDS (compare double and swap). > the instructions have since been expanded for 64-bit operation and a > new "perform locked operation" has since been added. Yup. I have actually conversed with Lynn over on comp.arch. Very smart person loaded up with knowledge. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 04 11:48AM -0700 On 11/4/2023 11:45 AM, Chris M. Thomasson wrote: >> new "perform locked operation" has since been added. > Yup. I have actually conversed with Lynn over on comp.arch. Very smart > person loaded up with knowledge. The free pool manipulation in IBM's principle of operations, iirc, its in an appendix. |
| BGB <cr88192@gmail.com>: Nov 04 02:18AM -0500 On 11/1/2023 5:55 PM, Jack wrote: > There is another server called "paganini.bofh.team". You don't need an > account but spam is not allowed. People abusing the server will have > their IP address blocked. IP blocking is a bit questionable though in this era of ISP grade NAT and similar (say, the IP address they see on their cable modem is 10.x.x.x; with some other IP address visible to the outside world), and with a dynamic external IP address. So, if one person is posting spam with a given ISP, then blocking fails to block the spammer (as their external IP keeps changing), but will ultimately end up blocking random other people who happen to have their traffic routed through an IP address which was previously used for spamming (well, at least until their ISP causes their connections to jump over to some other IP address that hasn't been blocked yet). ... It seems like a strategy that mostly (only) really makes sense in a context where one assumes that each node has a statically-assigned global IP address. |
| 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