Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #83760 > unrolled thread

"Performance of C++20's Ranges"

Back to article view | Back to comp.lang.c++

Contents

  "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 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#83871

On Thu, 28 Apr 2022 18:20:04 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> 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

Watch those goalposts move.

>spread over multiple processes. That's simply a mess to write and
>no one writes code like that today.

"No one" being you. Its can be far less messy than multi threaded because
you only need to worry about where the processes interact , not the entire
code where all the threads may interact in wierd ways.

>
>> 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.

I've written quite a few and probably debugged more than you've have hot
dinners. Debugging race conditions and deadlocks is a PITA and if you'd ever
done it you'd know why multi threading should only be used when the execution
paths and data need to be tightly coupled.

>> 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.

"sth"?

[toc] | [prev] | [next] | [standalone]

#83882

> "No one" being you. Its can be far less messy than multi threaded because
> you only need to worry about where the processes interact , not the entire
> code where all the threads may interact in wierd ways.

It's magnitudes more messy because you don't have a shared address
space.

> I've written quite a few and probably debugged more than you've have hot
> dinners. Debugging race conditions and deadlocks is a PITA and if you'd ever
> done it you'd know why multi threading should only be used when the execution
> paths and data need to be tightly coupled.

Race conditions and deadlocks are no issue if you know how to deal
with C++'s synchronization mechanisms. According to what you say
you've _never_ written MT-code for sure.

[toc] | [prev] | [next] | [standalone]

#83894

> "No one" being you. Its can be far less messy than multi threaded because
> you only need to worry about where the processes interact , not the entire
> code where all the threads may interact in wierd ways.

The problem with synchonizing separate processes is that you have to
serialize shared data structures scattered across your address space
into your shared memory segments. And you can't use normal pointers
since the logical addresses at which the shared memory segment starts
in different address spaces are not the same for all proceses. That's
all very complex and costly.

[toc] | [prev] | [next] | [standalone]

#83902

Bonita Montero <Bonita.Montero@gmail.com> writes:
>> "No one" being you. Its can be far less messy than multi threaded because
>> you only need to worry about where the processes interact , not the entire
>> code where all the threads may interact in wierd ways.
>
>The problem with synchonizing separate processes is that you have to
>serialize shared data structures scattered across your address space
>into your shared memory segments. And you can't use normal pointers
>since the logical addresses at which the shared memory segment starts
>in different address spaces are not the same for all proceses. That's
>all very complex and costly.

It is neither complex nor costly.  Certainly not "very".

For those lucky enough to use POSIX, mmap() is very useful
for such sharing (e.g. MAP_FIXED if one must use pointers
instead of offsets) and allows easy checkpointing
of the shared data.  And, of course, pthread_mutexattr_setpshared.

[toc] | [prev] | [next] | [standalone]

#83905

> It is neither complex nor costly.  Certainly not "very".

No, it is. Serializing your data strcutures into a shared
memory segment, having no absolute pointers, is a mess.

[toc] | [prev] | [next] | [standalone]

#83910

On Sat, 30 Apr 2022 17:31:19 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> "No one" being you. Its can be far less messy than multi threaded because
>>> you only need to worry about where the processes interact , not the entire
>>> code where all the threads may interact in wierd ways.
>>
>>The problem with synchonizing separate processes is that you have to
>>serialize shared data structures scattered across your address space
>>into your shared memory segments. And you can't use normal pointers
>>since the logical addresses at which the shared memory segment starts
>>in different address spaces are not the same for all proceses. That's
>>all very complex and costly.
>
>It is neither complex nor costly.  Certainly not "very".
>
>For those lucky enough to use POSIX, mmap() is very useful
>for such sharing (e.g. MAP_FIXED if one must use pointers
>instead of offsets) and allows easy checkpointing
>of the shared data.  And, of course, pthread_mutexattr_setpshared.

Using mutexes between seperate processes is extremely useful but I'm glad
I'm not the person who had to implement it as the code must be rather hairy 
under the hood given the processes could be executing on physically seperate 
CPUs, not just different cores as with threads.

[toc] | [prev] | [next] | [standalone]

#83911

> Using mutexes between seperate processes is extremely useful but I'm glad
> I'm not the person who had to implement it as the code must be rather hairy
> under the hood given the processes could be executing on physically seperate
> CPUs, not just different cores as with threads.

Futexes can be easily used across process-boundaries.
They also have some mechanisms that when a process crashes whith an
owned futex it gives up the ownership on the futex automaticallly.

But almost never makes sense to parallelize with multiple processes
because the parallel parts are so tightly coupled that not only a
single process should crash. And in addition parallelization with
multiple processes is very ugly to program.

[toc] | [prev] | [next] | [standalone]

#83912

On Sun, 1 May 2022 18:18:39 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Using mutexes between seperate processes is extremely useful but I'm glad
>> I'm not the person who had to implement it as the code must be rather hairy
>> under the hood given the processes could be executing on physically seperate
>> CPUs, not just different cores as with threads.
>
>Futexes can be easily used across process-boundaries.
>They also have some mechanisms that when a process crashes whith an
>owned futex it gives up the ownership on the futex automaticallly.
>
>But almost never makes sense to parallelize with multiple processes
>because the parallel parts are so tightly coupled that not only a
>single process should crash. And in addition parallelization with
>multiple processes is very ugly to program.

Threads and processes and different use cases. Tightly coupled data processing
would be better using threads. OTOH something that eg has to act as a TCP user
connection server such as sshd is better off with seperate processes. Of course
if its something like a web server where a browser may initiate dozens of 
transient connections a second the smaller creation and resourse allocation 
footprint of threads works better.

[toc] | [prev] | [next] | [standalone]

#83913

Muttley@dastardlyhq.com writes:
>On Sat, 30 Apr 2022 17:31:19 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:
>>Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>> "No one" being you. Its can be far less messy than multi threaded because
>>>> you only need to worry about where the processes interact , not the entire
>>>> code where all the threads may interact in wierd ways.
>>>
>>>The problem with synchonizing separate processes is that you have to
>>>serialize shared data structures scattered across your address space
>>>into your shared memory segments. And you can't use normal pointers
>>>since the logical addresses at which the shared memory segment starts
>>>in different address spaces are not the same for all proceses. That's
>>>all very complex and costly.
>>
>>It is neither complex nor costly.  Certainly not "very".
>>
>>For those lucky enough to use POSIX, mmap() is very useful
>>for such sharing (e.g. MAP_FIXED if one must use pointers
>>instead of offsets) and allows easy checkpointing
>>of the shared data.  And, of course, pthread_mutexattr_setpshared.
>
>Using mutexes between seperate processes is extremely useful but I'm glad
>I'm not the person who had to implement it as the code must be rather hairy 
>under the hood given the processes could be executing on physically seperate 
>CPUs, not just different cores as with threads.

Been there, done that.  To complicate it further, we had a single-system-image
across 64 nodes, all of which shared memory with varying latencies,
and we supported pthread shared mutexes and other internal synchronization
mechanisms thanks to a hardware ASIC that extended the coherency
domain across Infiniband.   LLNL had test program that hammered a cache
line from all cores on all nodes (each node was two-socket with 6-core Istanbul
chips) - which demonstrated, as expected, that one should not do
that.

[toc] | [prev] | [next] | [standalone]

#83915

On Thursday, April 28, 2022 at 9:02:44 AM UTC-7, Bonita Montero wrote:
> Am 28.04.2022 um 17:59 schrieb Mut...@dastardlyhq.com: 
> > On Thu, 28 Apr 2022 17:55:20 +0200 Bonita Montero 
> > <Bonita....@gmail.com> wrote: 
> >> Am 28.04.2022 um 17:50 schrieb Mut...@dastardlyhq.com: 
> >>> On Thu, 28 Apr 2022 17:31:41 +0200 Bonita Montero 
> >>> <Bonita....@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.


Isn't it a , ..., disk mount?

"Oracle" I think is a "disk mount".

What I mean by that is, ..., pretty usual in organization.

The "store", say, ....

Vis-a-vis the "core" -, ....

Excuse, I basically live in events instead of process.

Oracle, that is, ....

[toc] | [prev] | [next] | [standalone]

#83858

Muttley@dastardlyhq.com writes:
>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.

And he/she/it should also read:

https://www.thegeekdiary.com/oracle-12c-new-feature-multi-threaded-architecture-of-processes/

[toc] | [prev] | [next] | [standalone]

#83872

On Thu, 28 Apr 2022 18:21:08 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>Muttley@dastardlyhq.com writes:
>>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/backgroun
>d-
>>>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.
>
>And he/she/it should also read:
>
>https://www.thegeekdiary.com/oracle-12c-new-feature-multi-threaded-architecture
>-of-processes/

" to run as operating system threads in separate address spaces"

Whats that supposed to mean? 

[toc] | [prev] | [next] | [standalone]

#83857

Bonita Montero <Bonita.Montero@gmail.com> writes:
>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.

How much code in the Oracle RDBMS engine did you write[*]?  Are you familiar
with RAC (which used to be called OPS)?

[*] I have experience writing code in the Oracle RDBMS[**], albeit a quarter
    century ago.

[**] In C.  All identifiers were restricted 8 characters to support a wide
     range of compilers, so they used two and three-letter prefixes for the
     various subsystems (table handling, common functions, RBO, query engine, etc).

[toc] | [prev] | [next] | [standalone]

#83859

Am 28.04.2022 um 20:19 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> 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.
> 
> How much code in the Oracle RDBMS engine did you write[*]?  Are you familiar
> with RAC (which used to be called OPS)?

RAC has no multi-process architecture since the RAC-processes arent
shared on a single machine.

[toc] | [prev] | [next] | [standalone]

#83862

On 4/28/2022 8:17 AM, Muttley@dastardlyhq.com wrote:
> 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.
> 

True. I remember working with robust mutexes back in the day. 
EOWNERDEAD, and the fun WAIT_ABANDONED state for windows... ;^)

[toc] | [prev] | [next] | [standalone]

#83838

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".

1: No lock.
2: Write lock.
3: Read-write lock.

Quite simple to understand really even for you.

[toc] | [prev] | [next] | [standalone]

#83833

Muttley@dastardlyhq.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.
> 
> Why haven't the committee implemented multi-process support in C++? Oh wait,
> Windows multi-process model is a joke, thats why. Lowest common denominator
> wins again.

I find it a bit amusing how when a new C++ standard implements support for
some new thing, people complain that it's becoming too large and too
complex, and when the new C++ standard does *not* implement support for
something, that's also a reason to complain. It's like whatever they do,
it's wrong.

You do understand that it's better to have an easy-to-use portable way of
writing a multithreaded program, even if it doesn't support every single
thing that eg. the posix pthreads library supports, than nothing?

It's a bit like complaining that std::vector doesn't support "short vector
optimization" (like the Boost small_vector does). Sure, that's something
that could be sometimes useful. However, that doesn't mean there shouldn't
be a std::vector (as currently specified) at all. It's not an "all or
nothing" situation.

[toc] | [prev] | [next] | [standalone]

#83840

On Thu, 28 Apr 2022 10:57:55 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>Muttley@dastardlyhq.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.
>
>> 
>> Why haven't the committee implemented multi-process support in C++? Oh wait,
>> Windows multi-process model is a joke, thats why. Lowest common denominator
>> wins again.
>
>I find it a bit amusing how when a new C++ standard implements support for
>some new thing, people complain that it's becoming too large and too
>complex, and when the new C++ standard does *not* implement support for
>something, that's also a reason to complain. It's like whatever they do,
>it's wrong.

No, just pointing out a glaring inconsistency.

>You do understand that it's better to have an easy-to-use portable way of
>writing a multithreaded program, even if it doesn't support every single
>thing that eg. the posix pthreads library supports, than nothing?

And that doesn't apply to multi process?

>It's a bit like complaining that std::vector doesn't support "short vector

No, its like complaining the STL implemented vector but for 11 years still
hasn't bothered implementing list or queue.

[toc] | [prev] | [next] | [standalone]

#83856

On 4/28/2022 3:57 AM, Juha Nieminen wrote:

> I find it a bit amusing how when a new C++ standard implements support for
> some new thing, people complain that it's becoming too large and too
> complex, and when the new C++ standard does *not* implement support for
> something, that's also a reason to complain. It's like whatever they do,
> it's wrong.
> 

This seems relevant: 
https://i.pinimg.com/originals/6e/6c/1c/6e6c1c2990eb1bc352e29adb3cfef8ba.jpg

[toc] | [prev] | [next] | [standalone]

#83808

> Frankly IMO even adding threads to C++ was idiotic because they're limited
> to the lowest common denominator implementation (Windows) and hence don't
> have critical functionality such as 3 level locking. Also if the language
> supports threading, why not multi process too? Silly inconsistency.

For 99% of what MT-synchronization nedds C++'s mutexes and condition
variables are sufficient. The rest can be easily built with semaphores
and atomics. So there's really no limit of the platform since C++ could
supply additional synchronization-facilities built on the two components
the CPU and the operating system supplies on its own; it's typically not
necessary.

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.c++

csiph-web