| |||||||||||||
A look at C++14, part 1A look at C++14, part 1Posted Mar 30, 2013 17:55 UTC (Sat) by jwakely (subscriber, #60262)In reply to: A look at C++14, part 1 by simlo Parent article: A look at C++14, part 1
> What I oppose to, is having a C++ runtime assuming it is multi threaded, having the runtime system using atomic operations, when I want to stick to single threaded programs.
Use a better C++ runtime implementation then, don't argue the rest of us should always have to do things your way.
GCC can be configure with --disable-threads in which case there are no atomic operations used in the runtime. When configured with --enable-threads=posix (on a supported OS) the runtime still doesn't use atomic operations unless the program is linked with libpthread.so so single-threaded programs don't use atomic operations. So I don't really see what you're opposed to.
(Log in to post comments)
A look at C++14, part 1 Posted Mar 31, 2013 9:31 UTC (Sun) by simlo (subscriber, #10866) [Link]
What I am opposed to is multi threading!
My experience have shown me that it is the most misunderstood and amused feature in programming. Everybody learn about it in school and think they have to use it and impose it on everybody else. Once a program, framework or API relies on multithreading it is impossible to avoid. But in 95% of the cases the multi threading was complete unneeded if just the API were available in non-blocking versions.
Take Java: when you implement a TCP protocol you have a thread for receive, a thread for transmit and a timer to detect inactivity. Using select() you can do this in one thread avoiding a lot potential race conditions. I have seen instabilities and odd problems popping up in old Java programs due to this.
When using this model in C++ you get into further problems due to missing garbage collector.
In the beginning UNIX user space did not have multi threading. It is mostly a bad habit coming from other OS'es lacking proper processes.
I am not totally against multi threading: realtime system and system with heavy scale able algorithms. But 95% of programs only becomes unstable and much harder to maintain due to threads.
A look at C++14, part 1 Posted Mar 31, 2013 13:59 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
I haven't seen real Java apps using separate threads to receive and send data. That's simply stupid in most cases. However, I did see asynchronous servers die under a high load with all but one CPU completely idle.
A look at C++14, part 1 Posted Mar 31, 2013 21:08 UTC (Sun) by simlo (subscriber, #10866) [Link]
Well, as I work with _real_ Java programs (written before select() came to Java), I know it is needed.
For instance: I have some data I have to send to different clients via TCP sockets. Naive solution: Loop through the clients and perform write() on each socket. Problem: If one client is not taking data the write() operation will block halting data for any other client as well.
On a proper OS (i.e. UNIX) in C++, I can use select() and therefore contain everything in one thread and have a clear picture of my possible states.
A look at C++14, part 1 Posted Apr 2, 2013 4:28 UTC (Tue) by akeane (subscriber, #85436) [Link]
>What I am opposed to is multi threading!
Hooray, finally, a sane voice in the wilderness!
>the most misunderstood and _amused_ feature in programming.
This may be a typo, but yet it is brilliant somehow, I have always regarded pthreads as some evil entity laughing maliciously as some hapless programmer stumbles into it's wake...
If only I had a dollar for every sleep() I have seen to try to push that pesky race condition further into the sunset, and the amount of times I have seen assumptions being made about thread startup time and executions.
Or the nested locks, Oh God, the nested locks!
But back to pipelines in C++, surely the UNIX way would be to write some kind of general program which you could tell the system to take the output of one program and "pipe" it into another. I would call it:
/bin/M*A*S*H
Merry Easter
A look at C++14, part 1 Posted Apr 2, 2013 8:25 UTC (Tue) by jwakely (subscriber, #60262) [Link]
> But back to pipelines in C++, surely the UNIX way would be to write some kind of general program which you could tell the system to take the output of one program and "pipe" it into another.
Shameless plug: http://pstreams.sourceforge.net/
A look at C++14, part 1 Posted Mar 31, 2013 14:04 UTC (Sun) by nix (subscriber, #2304) [Link]
Well, sort of. An awful lot of libraries pull in libpthread just in case they are used with threaded programs. Nonthreaded programs then pull in libpthread transitively, and suddenly get hit with pointless locking overhead even though they will never have more than one thread.
Hell, on my system even ls(1) is linked with libpthread (though that is via librt because of a use of clock_gettime() and will presumably go away when it is rebuilt against glibc 2.17+.)
A look at C++14, part 1 Posted Mar 31, 2013 18:46 UTC (Sun) by jwakely (subscriber, #60262) [Link]
> An awful lot of libraries pull in libpthread just in case they are used with threaded programs.
This is not the C++ runtime's fault though, libstdc++ goes to a lot of effort to avoid locking in non-threaded programs, but sufficiently motivated fools^Wprogrammers can defeat that effort.
If you really need to skin that cat you can build GCC with --disable-threads and use that libstdc++.so
A look at C++14, part 1 Posted Apr 1, 2013 23:03 UTC (Mon) by nix (subscriber, #2304) [Link]
Indeed. Unfortunately, a lot of programmers don't realize they can use pthread locking functions even without linking to libpthread, getting stubs unless something else has loaded libpthread. The total lack of glibc libpthread documentation might explain this :)
(actually, I can't remember if they're stubs or weak symbols. Stubs, I think, so you don't even need to wrap their uses in null checks.)
|
|||||||||||||