Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #83760 > unrolled thread
| Started by | Cholo Lennon <chololennon@hotmail.com> |
|---|---|
| First post | 2022-04-26 01:13 -0300 |
| Last post | 2022-04-27 18:35 +0200 |
| Articles | 20 on this page of 82 — 14 participants |
Back to article view | Back to comp.lang.c++
"Performance of C++20's Ranges" Cholo Lennon <chololennon@hotmail.com> - 2022-04-26 01:13 -0300
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-26 09:15 +0000
Re: "Performance of C++20's Ranges" Juha Nieminen <nospam@thanks.invalid> - 2022-04-26 09:27 +0000
Re: "Performance of C++20's Ranges" Manfred <noname@add.invalid> - 2022-04-26 16:29 +0200
Re: "Performance of C++20's Ranges" "Ross A. Finlayson" <ross.finlayson@gmail.com> - 2022-05-01 18:45 -0700
Re: "Performance of C++20's Ranges" "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-04-26 11:42 +0200
Re: "Performance of C++20's Ranges" Juha Nieminen <nospam@thanks.invalid> - 2022-04-26 11:11 +0000
Re: "Performance of C++20's Ranges" "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-04-26 13:31 +0200
Re: "Performance of C++20's Ranges" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-26 06:46 -0700
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-27 08:20 +0000
Re: "Performance of C++20's Ranges" Juha Nieminen <nospam@thanks.invalid> - 2022-04-27 08:40 +0000
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-27 15:12 +0000
Re: "Performance of C++20's Ranges" scott@slp53.sl.home (Scott Lurndal) - 2022-04-27 16:09 +0000
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-27 16:21 +0000
Re: "Performance of C++20's Ranges" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-29 16:15 -0700
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-30 16:00 +0000
Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-27 19:03 +0200
Re: "Performance of C++20's Ranges" James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-27 11:12 -0400
Re: "Performance of C++20's Ranges" Juha Nieminen <nospam@thanks.invalid> - 2022-04-28 06:45 +0000
Re: "Performance of C++20's Ranges" Juha Nieminen <nospam@thanks.invalid> - 2022-04-27 06:30 +0000
Re: "Performance of C++20's Ranges" Manfred <noname@add.invalid> - 2022-04-28 23:57 +0200
Re: "Performance of C++20's Ranges" Juha Nieminen <nospam@thanks.invalid> - 2022-04-29 06:07 +0000
Re: "Performance of C++20's Ranges" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-29 16:28 -0700
Re: "Performance of C++20's Ranges" Juha Nieminen <nospam@thanks.invalid> - 2022-05-02 05:01 +0000
Re: "Performance of C++20's Ranges" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-10 07:36 -0700
Re: "Performance of C++20's Ranges" James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-26 11:28 -0400
Re: "Performance of C++20's Ranges" Manfred <noname@add.invalid> - 2022-04-26 18:13 +0200
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-26 16:24 +0000
Re: "Performance of C++20's Ranges" James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-26 12:48 -0400
Re: "Performance of C++20's Ranges" Cholo Lennon <chololennon@hotmail.com> - 2022-04-26 20:20 -0300
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-27 08:30 +0000
Re: "Performance of C++20's Ranges" Juha Nieminen <nospam@thanks.invalid> - 2022-04-27 08:50 +0000
Re: "Performance of C++20's Ranges" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-27 05:12 -0700
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-27 15:18 +0000
Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-27 18:56 +0200
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 08:40 +0000
Re: "Performance of C++20's Ranges" Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-28 13:54 +0300
Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 13:11 +0200
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 15:25 +0000
Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 17:30 +0200
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 15:45 +0000
Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 17:52 +0200
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 15:57 +0000
Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 18:01 +0200
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 16:06 +0000
Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 18:09 +0200
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 16:14 +0000
Re: "Performance of C++20's Ranges" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-04-28 16:11 -0700
Re: "Performance of C++20's Ranges" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-04-28 16:20 -0700
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-29 09:31 +0000
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 15:15 +0000
Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 13:07 +0200
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 15:17 +0000
Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 17:31 +0200
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 15:50 +0000
Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 17:55 +0200
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 15:59 +0000
Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 18:02 +0200
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 16:13 +0000
Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 18:20 +0200
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-29 09:27 +0000
Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-29 20:48 +0200
Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-30 07:34 +0200
Re: "Performance of C++20's Ranges" scott@slp53.sl.home (Scott Lurndal) - 2022-04-30 17:31 +0000
Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-30 20:30 +0200
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-05-01 15:20 +0000
Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-01 18:18 +0200
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-05-01 16:25 +0000
Re: "Performance of C++20's Ranges" scott@slp53.sl.home (Scott Lurndal) - 2022-05-01 23:14 +0000
Re: "Performance of C++20's Ranges" "Ross A. Finlayson" <ross.finlayson@gmail.com> - 2022-05-01 18:52 -0700
Re: "Performance of C++20's Ranges" scott@slp53.sl.home (Scott Lurndal) - 2022-04-28 18:21 +0000
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-29 09:29 +0000
Re: "Performance of C++20's Ranges" scott@slp53.sl.home (Scott Lurndal) - 2022-04-28 18:19 +0000
Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-28 21:01 +0200
Re: "Performance of C++20's Ranges" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-04-28 16:07 -0700
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 15:22 +0000
Re: "Performance of C++20's Ranges" Juha Nieminen <nospam@thanks.invalid> - 2022-04-28 10:57 +0000
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-28 15:27 +0000
Re: "Performance of C++20's Ranges" red floyd <no.spam.here@its.invalid> - 2022-04-28 09:26 -0700
Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-27 17:07 +0200
Re: "Performance of C++20's Ranges" Muttley@dastardlyhq.com - 2022-04-27 15:54 +0000
Re: "Performance of C++20's Ranges" Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-27 18:35 +0200
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-04-28 15:45 +0000 |
| Message-ID | <t4ecq9$mmp$1@gioia.aioe.org> |
| In reply to | #83841 |
On Thu, 28 Apr 2022 17:30:37 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >> So what does your code do if there are still threads reading the data and >> another wants to write? Suddenly block the read threads and revoke their >locks? >> Otherwise how do you solve the "all readers have relinquished ownership" >> problem? > >It behaves exactly like other shared locks, but once a writer has >registered as wanting to have write-access all further readers are >enqueued. Write locks should always take priority. I'd be surprised if shared_lock doesn't behave like that. >> What a fucking mess. > >No, working elegant code. For which definition of "elegant"?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-04-28 17:52 +0200 |
| Message-ID | <t4ed7o$vm6$1@dont-email.me> |
| In reply to | #83843 |
Am 28.04.2022 um 17:45 schrieb Muttley@dastardlyhq.com: > On Thu, 28 Apr 2022 17:30:37 +0200 > Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> So what does your code do if there are still threads reading the data and >>> another wants to write? Suddenly block the read threads and revoke their >> locks? >>> Otherwise how do you solve the "all readers have relinquished ownership" >>> problem? >> >> It behaves exactly like other shared locks, but once a writer has >> registered as wanting to have write-access all further readers are >> enqueued. > > Write locks should always take priority. I'd be surprised if shared_lock > doesn't behave like that. That's impossible, readers can hold the lock in read-state as long as they want. The only way to give writers priority is to enqueue further readers. >>> What a fucking mess. >> >> No, working elegant code. > > For which definition of "elegant"? You're don't understand it so you can't say it's not elegant. It's usable as convenient as a mutex through a std::lock or std::unique_lock.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-04-28 15:57 +0000 |
| Message-ID | <t4edgo$12a8$1@gioia.aioe.org> |
| In reply to | #83845 |
On Thu, 28 Apr 2022 17:52:47 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >Am 28.04.2022 um 17:45 schrieb Muttley@dastardlyhq.com: >> On Thu, 28 Apr 2022 17:30:37 +0200 >> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>> So what does your code do if there are still threads reading the data and >>>> another wants to write? Suddenly block the read threads and revoke their >>> locks? >>>> Otherwise how do you solve the "all readers have relinquished ownership" >>>> problem? >>> >>> It behaves exactly like other shared locks, but once a writer has >>> registered as wanting to have write-access all further readers are >>> enqueued. >> >> Write locks should always take priority. I'd be surprised if shared_lock >> doesn't behave like that. > >That's impossible, readers can hold the lock in read-state as long Well yes, if they're currently reading. What would you suggest happens, the writer is allowed to write while the readers are reading and so you end up with a load of dirty reads? Not clever. >as they want. The only way to give writers priority is to enqueue >further readers. Errr yeees. If a write lock is requested it should get priority over any read locks currently requested. >>> No, working elegant code. >> >> For which definition of "elegant"? > >You're don't understand it so you can't say it's not elegant. Working and elegant are not the same thing.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-04-28 18:01 +0200 |
| Message-ID | <t4ednk$7t0$1@dont-email.me> |
| In reply to | #83847 |
Am 28.04.2022 um 17:57 schrieb Muttley@dastardlyhq.com: > On Thu, 28 Apr 2022 17:52:47 +0200 > Bonita Montero <Bonita.Montero@gmail.com> wrote: >> Am 28.04.2022 um 17:45 schrieb Muttley@dastardlyhq.com: >>> On Thu, 28 Apr 2022 17:30:37 +0200 >>> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>>> So what does your code do if there are still threads reading the data and >>>>> another wants to write? Suddenly block the read threads and revoke their >>>> locks? >>>>> Otherwise how do you solve the "all readers have relinquished ownership" >>>>> problem? >>>> >>>> It behaves exactly like other shared locks, but once a writer has >>>> registered as wanting to have write-access all further readers are >>>> enqueued. >>> >>> Write locks should always take priority. I'd be surprised if shared_lock >>> doesn't behave like that. >> >> That's impossible, readers can hold the lock in read-state as long > > Well yes, if they're currently reading. What would you suggest happens, the > writer is allowed to write while the readers are reading and so you end up > with a load of dirty reads? Not clever. *facepalm* Please read this article: https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock > Errr yeees. If a write lock is requested it should get priority over any read > locks currently requested. Only relative priority since the current readers could theroretically hold the lock in read-state as long as they want. > Working and elegant are not the same thing. You don't understand the code, not at the least part.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-04-28 16:06 +0000 |
| Message-ID | <t4ee2k$1bgv$1@gioia.aioe.org> |
| In reply to | #83849 |
On Thu, 28 Apr 2022 18:01:15 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >Am 28.04.2022 um 17:57 schrieb Muttley@dastardlyhq.com: >> On Thu, 28 Apr 2022 17:52:47 +0200 >> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Am 28.04.2022 um 17:45 schrieb Muttley@dastardlyhq.com: >>>> On Thu, 28 Apr 2022 17:30:37 +0200 >>>> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>>>> So what does your code do if there are still threads reading the data and > >>>>>> another wants to write? Suddenly block the read threads and revoke their >>>>> locks? >>>>>> Otherwise how do you solve the "all readers have relinquished ownership" >>>>>> problem? >>>>> >>>>> It behaves exactly like other shared locks, but once a writer has >>>>> registered as wanting to have write-access all further readers are >>>>> enqueued. >>>> >>>> Write locks should always take priority. I'd be surprised if shared_lock >>>> doesn't behave like that. >>> >>> That's impossible, readers can hold the lock in read-state as long >> >> Well yes, if they're currently reading. What would you suggest happens, the >> writer is allowed to write while the readers are reading and so you end up >> with a load of dirty reads? Not clever. > >*facepalm* >Please read this article: >https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock Yes, and? Perhaps you need to revisit what you wrote. >> Errr yeees. If a write lock is requested it should get priority over any read > >> locks currently requested. > >Only relative priority since the current readers could theroretically >hold the lock in read-state as long as they want. Well of course they could, thats the whole point of a lock FFS! I'm not sure what you're arguing here. >> Working and elegant are not the same thing. > >You don't understand the code, not at the least part. From the code you've shown on here its clear you're not capable of writing clear, readable code. This is no exception.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-04-28 18:09 +0200 |
| Message-ID | <t4ee71$hjo$1@dont-email.me> |
| In reply to | #83851 |
> Yes, and? Perhaps you need to revisit what you wrote. You don't completely understand what a readers writer lock does. > Well of course they could, thats the whole point of a lock FFS! I'm not sure > what you're arguing here. No, absolutely not. There is no implementation of a readers writer lock that can stop readers from holding the lock an inefinite time. > From the code you've shown on here its clear you're not capable of writing > clear, readable code. This is no exception. The code is easy to read for people who know how the innards of synchronization works. You have absolutely no knowledge in that.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-04-28 16:14 +0000 |
| Message-ID | <t4eehg$1ijg$1@gioia.aioe.org> |
| In reply to | #83852 |
On Thu, 28 Apr 2022 18:09:28 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >> Yes, and? Perhaps you need to revisit what you wrote. > >You don't completely understand what a readers writer lock does. > >> Well of course they could, thats the whole point of a lock FFS! I'm not sure >> what you're arguing here. > >No, absolutely not. There is no implementation of a readers writer >lock that can stop readers from holding the lock an inefinite time. Huh? Where did I say there was? You seem to be arguing with yourself. Anyway, enough of this for today, I'm getting bored with your nonsense.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-04-28 16:11 -0700 |
| Message-ID | <t4f6us$i9d$4@dont-email.me> |
| In reply to | #83839 |
On 4/28/2022 8:25 AM, Muttley@dastardlyhq.com wrote: > On Thu, 28 Apr 2022 13:11:48 +0200 > Bonita Montero <Bonita.Montero@gmail.com> wrote: >> Am 28.04.2022 um 12:54 schrieb Paavo Helde: >>> 28.04.2022 11:40 Muttley@dastardlyhq.com kirjutas: >>>> On Wed, 27 Apr 2022 18:56:06 +0200 >>>> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>>>> If I need 3 level locking (which I do in most threaded programs) >>>>>> then its >>>>>> pthreads for me because the simpleton C++ threading model doesn't >>>>>> support it. >>>>> >>>>> >>>>> What's "3 level locking" ? Description / URL ? >>>> >>>> You are kidding me, right? You spout off about threading all the time and >>>> you don't know the fundamentals? Educate yourself: >>>> >>>> https://www.ibm.com/docs/en/aix/7.2?topic=programming-using-readwrite-locks >> >>>> >>> >>> And read-write locks have been in C++ standard since 2017: >>> https://en.cppreference.com/w/cpp/thread/shared_mutex >> >> This kind of shared lock is almost useless since it gives >> readers priority over writers so that the writer can proceed >> only if all readers have relinquished ownership. With my >> shared lock, all further readers are enqueued when a writer >> wants to gain ownership and the lock lets proceed the preceding >> readers. > > So what does your code do if there are still threads reading the data and > another wants to write? Suddenly block the read threads and revoke their locks? > Otherwise how do you solve the "all readers have relinquished ownership" > problem? > >> Here's the code: > > What a fucking mess. > Check this one out I programmed many moons ago: https://vorbrodt.blog/2019/02/14/read-write-mutex/ It's very simple, and uses a bakery algorithm so its 100% fair.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2022-04-28 16:20 -0700 |
| Message-ID | <t4f7g0$og2$1@dont-email.me> |
| In reply to | #83863 |
On 4/28/2022 4:11 PM, Chris M. Thomasson wrote: > On 4/28/2022 8:25 AM, Muttley@dastardlyhq.com wrote: >> On Thu, 28 Apr 2022 13:11:48 +0200 >> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Am 28.04.2022 um 12:54 schrieb Paavo Helde: >>>> 28.04.2022 11:40 Muttley@dastardlyhq.com kirjutas: >>>>> On Wed, 27 Apr 2022 18:56:06 +0200 >>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>>>>> If I need 3 level locking (which I do in most threaded programs) >>>>>>> then its >>>>>>> pthreads for me because the simpleton C++ threading model doesn't >>>>>>> support it. >>>>>> >>>>>> >>>>>> What's "3 level locking" ? Description / URL ? >>>>> >>>>> You are kidding me, right? You spout off about threading all the >>>>> time and >>>>> you don't know the fundamentals? Educate yourself: >>>>> >>>>> https://www.ibm.com/docs/en/aix/7.2?topic=programming-using-readwrite-locks >>>>> >>> >>>>> >>>> >>>> And read-write locks have been in C++ standard since 2017: >>>> https://en.cppreference.com/w/cpp/thread/shared_mutex >>> >>> This kind of shared lock is almost useless since it gives >>> readers priority over writers so that the writer can proceed >>> only if all readers have relinquished ownership. With my >>> shared lock, all further readers are enqueued when a writer >>> wants to gain ownership and the lock lets proceed the preceding >>> readers. >> >> So what does your code do if there are still threads reading the data and >> another wants to write? Suddenly block the read threads and revoke >> their locks? >> Otherwise how do you solve the "all readers have relinquished ownership" >> problem? >> >>> Here's the code: >> >> What a fucking mess. >> > > Check this one out I programmed many moons ago: > > https://vorbrodt.blog/2019/02/14/read-write-mutex/ > > It's very simple, and uses a bakery algorithm so its 100% fair. https://pastebin.com/raw/xCBHY9qd
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-04-29 09:31 +0000 |
| Message-ID | <t4gb9m$1he4$1@gioia.aioe.org> |
| In reply to | #83863 |
On Thu, 28 Apr 2022 16:11:25 -0700 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote: >On 4/28/2022 8:25 AM, Muttley@dastardlyhq.com wrote: >> On Thu, 28 Apr 2022 13:11:48 +0200 >> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Am 28.04.2022 um 12:54 schrieb Paavo Helde: >>>> 28.04.2022 11:40 Muttley@dastardlyhq.com kirjutas: >>>>> On Wed, 27 Apr 2022 18:56:06 +0200 >>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>>>>> If I need 3 level locking (which I do in most threaded programs) >>>>>>> then its >>>>>>> pthreads for me because the simpleton C++ threading model doesn't >>>>>>> support it. >>>>>> >>>>>> >>>>>> What's "3 level locking" ? Description / URL ? >>>>> >>>>> You are kidding me, right? You spout off about threading all the time and >>>>> you don't know the fundamentals? Educate yourself: >>>>> >>>>> >https://www.ibm.com/docs/en/aix/7.2?topic=programming-using-readwrite-locks >>> >>>>> >>>> >>>> And read-write locks have been in C++ standard since 2017: >>>> https://en.cppreference.com/w/cpp/thread/shared_mutex >>> >>> This kind of shared lock is almost useless since it gives >>> readers priority over writers so that the writer can proceed >>> only if all readers have relinquished ownership. With my >>> shared lock, all further readers are enqueued when a writer >>> wants to gain ownership and the lock lets proceed the preceding >>> readers. >> >> So what does your code do if there are still threads reading the data and >> another wants to write? Suddenly block the read threads and revoke their >locks? >> Otherwise how do you solve the "all readers have relinquished ownership" >> problem? >> >>> Here's the code: >> >> What a fucking mess. >> > >Check this one out I programmed many moons ago: > >https://vorbrodt.blog/2019/02/14/read-write-mutex/ > >It's very simple, and uses a bakery algorithm so its 100% fair. Much nicer. Don't know what the bakery algorithm is, will have to google, but that is the kind of code I'd expect. Not the use-every-C++-feature-I-can-think -of wankery that Bonita comes up with.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-04-28 15:15 +0000 |
| Message-ID | <t4eb2a$1pk3$1@gioia.aioe.org> |
| In reply to | #83832 |
On Thu, 28 Apr 2022 13:54:22 +0300 Paavo Helde <eesnimi@osa.pri.ee> wrote: >28.04.2022 11:40 Muttley@dastardlyhq.com kirjutas: >> On Wed, 27 Apr 2022 18:56:06 +0200 >> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>> If I need 3 level locking (which I do in most threaded programs) then its >>>> pthreads for me because the simpleton C++ threading model doesn't support >it. >>> >>> >>> What's "3 level locking" ? Description / URL ? >> >> You are kidding me, right? You spout off about threading all the time and >> you don't know the fundamentals? Educate yourself: >> >> https://www.ibm.com/docs/en/aix/7.2?topic=programming-using-readwrite-locks > >And read-write locks have been in C++ standard since 2017: > >https://en.cppreference.com/w/cpp/thread/shared_mutex > Yes, the functionality looks the same. When I went googling for this in C++ shared_locks never came up. I supposed because they use different terminology. Anyway, good to know its finally in there and I take back what I said.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-04-28 13:07 +0200 |
| Message-ID | <t4dsgv$uaq$1@dont-email.me> |
| In reply to | #83829 |
Am 28.04.2022 um 10:40 schrieb Muttley@dastardlyhq.com: > On Wed, 27 Apr 2022 18:56:06 +0200 > Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> If I need 3 level locking (which I do in most threaded programs) then its >>> pthreads for me because the simpleton C++ threading model doesn't support it. >> >> >> What's "3 level locking" ? Description / URL ? > > You are kidding me, right? You spout off about threading all the time and > you don't know the fundamentals? Educate yourself: > > https://www.ibm.com/docs/en/aix/7.2?topic=programming-using-readwrite-locks I know what RW-locks are and I've developed such a lock on my own (I've posted my implementation there that inherited glibc's spinning -algorithm). But that has nothing to do with the word "three level lock". > Sure. Remind me, whats the win32 equivalent of fork() again? fork() isn't necessaray, threading has superseded fork()ing.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-04-28 15:17 +0000 |
| Message-ID | <t4eb6t$1rop$1@gioia.aioe.org> |
| In reply to | #83834 |
On Thu, 28 Apr 2022 13:07:34 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >Am 28.04.2022 um 10:40 schrieb Muttley@dastardlyhq.com: >> On Wed, 27 Apr 2022 18:56:06 +0200 >> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>> If I need 3 level locking (which I do in most threaded programs) then its >>>> pthreads for me because the simpleton C++ threading model doesn't support >it. >>> >>> >>> What's "3 level locking" ? Description / URL ? >> >> You are kidding me, right? You spout off about threading all the time and >> you don't know the fundamentals? Educate yourself: >> >> https://www.ibm.com/docs/en/aix/7.2?topic=programming-using-readwrite-locks > >I know what RW-locks are and I've developed such a lock on my own >(I've posted my implementation there that inherited glibc's spinning >-algorithm). >But that has nothing to do with the word "three level lock". > >> Sure. Remind me, whats the win32 equivalent of fork() again? > >fork() isn't necessaray, threading has superseded fork()ing. Says someone who clearly doesn't understand the pros and cons of multi process vs multi threading. Hint: They have different use cases. One of the main ones being if a child process crashes it doesn't take down the parent process so for mission critical servers THIS MATTERS. If a child thread crashes the whole process is toast.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-04-28 17:31 +0200 |
| Message-ID | <t4ec06$1o7$2@dont-email.me> |
| In reply to | #83837 |
> Says someone who clearly doesn't understand the pros and cons of multi process > vs multi threading. Hint: They have different use cases. ... Multi-threading has superseeded fork()ed code. Even Oracle is completely multi-threaded today on Unices.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-04-28 15:50 +0000 |
| Message-ID | <t4ed3q$rvq$1@gioia.aioe.org> |
| In reply to | #83842 |
On Thu, 28 Apr 2022 17:31:41 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >> Says someone who clearly doesn't understand the pros and cons of multi >process >> vs multi threading. Hint: They have different use cases. ... > >Multi-threading has superseeded fork()ed code. In some places, not all. As I said, use cases. >Even Oracle is completely multi-threaded today on Unices. Configurable. https://docs.oracle.com/en/database/oracle/oracle-database/21/refrn/background-p rocesses.html
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-04-28 17:55 +0200 |
| Message-ID | <t4edch$vm6$2@dont-email.me> |
| In reply to | #83844 |
Am 28.04.2022 um 17:50 schrieb Muttley@dastardlyhq.com: > On Thu, 28 Apr 2022 17:31:41 +0200 > Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Says someone who clearly doesn't understand the pros and cons of multi >> process >>> vs multi threading. Hint: They have different use cases. ... >> >> Multi-threading has superseeded fork()ed code. > > In some places, not all. As I said, use cases. These places are rare today. Having complex iteraction between processes is very inconvenient for a software developer. >> Even Oracle is completely multi-threaded today on Unices. > > Configurable. > https://docs.oracle.com/en/database/oracle/oracle-database/21/refrn/background-p > rocesses.html Oracle has its own terms of what a process is and this is historically defined from times where Oracle wasn't multi-threaded.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-04-28 15:59 +0000 |
| Message-ID | <t4edld$14lh$1@gioia.aioe.org> |
| In reply to | #83846 |
On Thu, 28 Apr 2022 17:55:20 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >Am 28.04.2022 um 17:50 schrieb Muttley@dastardlyhq.com: >> On Thu, 28 Apr 2022 17:31:41 +0200 >> Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>> Says someone who clearly doesn't understand the pros and cons of multi >>> process >>>> vs multi threading. Hint: They have different use cases. ... >>> >>> Multi-threading has superseeded fork()ed code. >> >> In some places, not all. As I said, use cases. > >These places are rare today. Not in unix they're not. >Having complex iteraction between processes is very >inconvenient for a software developer. Not really. You've heard of pipes, signals, shared memory, semaphores, sockets? I'd sooner deal with those than endless race conditions from multiple threads. >> >https://docs.oracle.com/en/database/oracle/oracle-database/21/refrn/background- >p >> rocesses.html > >Oracle has its own terms of what a process is and this is historically >defined from times where Oracle wasn't multi-threaded. I suggest you read it.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-04-28 18:02 +0200 |
| Message-ID | <t4edqk$7t0$2@dont-email.me> |
| In reply to | #83848 |
Am 28.04.2022 um 17:59 schrieb Muttley@dastardlyhq.com: > On Thu, 28 Apr 2022 17:55:20 +0200 Bonita Montero > <Bonita.Montero@gmail.com> wrote: >> Am 28.04.2022 um 17:50 schrieb Muttley@dastardlyhq.com: >>> On Thu, 28 Apr 2022 17:31:41 +0200 Bonita Montero >>> <Bonita.Montero@gmail.com> wrote: >>>>> Says someone who clearly doesn't understand the pros and cons >>>>> of multi >>>> process >>>>> vs multi threading. Hint: They have different use cases. ... >>>> >>>> Multi-threading has superseeded fork()ed code. >>> >>> In some places, not all. As I said, use cases. >> >> These places are rare today. > > Not in unix they're not. Even in most Unix application. fork()ing is outdated for at least 10 years. > Not really. You've heard of pipes, signals, shared memory, > semaphores, sockets? I'd sooner deal with those than endless race > conditions from multiple threads. Having a shared address space is magnitudes more convenient and a lot faster. > I suggest you read it. You have to read it. I'm an Oralce OCP DBA.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-04-28 16:13 +0000 |
| Message-ID | <t4eeek$1gsr$1@gioia.aioe.org> |
| In reply to | #83850 |
On Thu, 28 Apr 2022 18:02:51 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >Am 28.04.2022 um 17:59 schrieb Muttley@dastardlyhq.com: >> On Thu, 28 Apr 2022 17:55:20 +0200 Bonita Montero >> <Bonita.Montero@gmail.com> wrote: >>> Am 28.04.2022 um 17:50 schrieb Muttley@dastardlyhq.com: >>>> On Thu, 28 Apr 2022 17:31:41 +0200 Bonita Montero >>>> <Bonita.Montero@gmail.com> wrote: >>>>>> Says someone who clearly doesn't understand the pros and cons >>>>>> of multi >>>>> process >>>>>> vs multi threading. Hint: They have different use cases. ... >>>>> >>>>> Multi-threading has superseeded fork()ed code. >>>> >>>> In some places, not all. As I said, use cases. >>> >>> These places are rare today. >> >> Not in unix they're not. > >Even in most Unix application. >fork()ing is outdated for at least 10 years. How do you think a shell executes sub processes and communicates with them and/or pipes them together? Then there are shell co processes too. >> Not really. You've heard of pipes, signals, shared memory, >> semaphores, sockets? I'd sooner deal with those than endless race >> conditions from multiple threads. > >Having a shared address space is magnitudes more convenient and >a lot faster. What do you think shared memory is? You can even have pthread mutexes mapped to it to use inter process. >> I suggest you read it. > >You have to read it. >I'm an Oralce OCP DBA. Oooh, an OCP, look at you! On windows no doubt so you have no idea of a unix enviroment. Oracle has little choice on windows to use far more threading.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-04-28 18:20 +0200 |
| Message-ID | <t4eeqs$v6e$1@dont-email.me> |
| In reply to | #83853 |
> How do you think a shell executes sub processes and communicates with > them and/or pipes them together? Then there are shell co processes too. That's sth. completely differen than having a single application spread over multiple processes. That's simply a mess to write and no one writes code like that today. > What do you think shared memory is? You can even have pthread mutexes mapped > to it to use inter process. You have never written an MT-application. That's magnitudes more convenient. > Oooh, an OCP, look at you! On windows no doubt so you have no idea of a unix > enviroment. Oracle has little choice on windows to use far more threading. Oracle doesn't support sth. different than MT-code on Unices for years.
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web