| |||||||||||||
A look at C++14, part 1A look at C++14, part 1Posted Mar 30, 2013 8:44 UTC (Sat) by alankila (subscriber, #47141)In reply to: A look at C++14, part 1 by simlo Parent article: A look at C++14, part 1
I suggest that you can't somehow smuggle in multiprocessing without encountering at least some of the hardships you suggest are exclusive to using threads. For instance, if you want to do multiprocessing and communicate using sockets or pipes, you could just as well use a producer-consumer pattern with threads and maintain the level of discipline in your threads that you know they don't need locking because all the resources they need for their work are local to the thread or just immutable.
Multiprocessing has one giant downside that always hits me in practice: the need to serialize and unserialize the datastructures that represent the work items and the results. This is pure overhead. In general the fact that threads can communicate with each other directly is their blessing and curse, but so far the blessings have been much larger to me, so I prefer code based on threads over the other means of achieving concurrency.
(Log in to post comments)
A look at C++14, part 1 Posted Mar 30, 2013 11:18 UTC (Sat) by simlo (subscriber, #10866) [Link]
As I see it there are 3 levels of concurrency
1) Use of explicit locks (as in the Linux kernel)
2) Message queues between threads, where data structures are owned by one thread avoiding the need for locks.
3) Messages queues in the form of pipes and sockets between processes.
1) is clearly the hardest to code. In principle it scales well of an unlimited amount of CPUs but it will often it ends up in lock congestion, where every thread waits for a specific resource. There is also a huge runtime overhead in managing the locks and logic around it.
2) and 3) are almost the same. 3) has the downside as you say that everything has to be serialized, which is a (huge) overhead. The upside is that individual processes can crash independently making it a lot easier to debug. You can also use sockets as a debug output, such the system can be inspected while running. 3) also have the possibility to move some of the system to a another machine.
But with a well written framework, where the communication channels are abstracted, 3) can be made into 2) without changing the core application code. No matter if you use 2) or 3), you have to use the same state machines in the application to handle the concurrency problems.
But once the application is written with explicit locks as under 1), there is no way back.
My advice is thus: Start by using 3). With templates and well a well written framework it is really not that hard to avoid threads. Then if the overhead of serialization is too high, merge the processes as in 2).
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. And what I argue for, is that most people ought to stick to single threaded programs anyway!
A look at C++14, part 1 Posted Mar 30, 2013 17:55 UTC (Sat) by jwakely (subscriber, #60262) [Link]
> 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.
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.)
|
|||||||||||||