Is the multi-threading model the real reason why OOP is falling and fP rising?

Question

I been looking around at the problem of the multi-core chip stuff. would I be correct in assuming that the real problem with developing for mutlicore chips is nothing to do with the actual techniques of multi-tasking (isolated memory, task based etc), but more to do with the implementation of the threading model in the OS?

I have been investigating Co-Routines and implementing them in c#,f# and python. So far they succeed very well apart from the creating the sub system and redeveloping a new sub system for every other system part, which is tiresome to say the least.

Is there a better model out there that comes "out of the box" that would serve me better and equally performant as co-routines.

Answer 1

Well, I don't think FP magically makes code better multi-threaded than OOP. Well written Java and C++ can still do some pretty amazing parallel performance, certainly in the range of cores we can currently get on commodity servers (8-24 core range).

Personally, I am looking at FP more as a way to get more done per line of code. I like dense code. I write code I want to go fast all the time in Java, and so far the paradigm holds... just a lot of ceremony and bloat I would rather not have to write.

P.S. I wouldn't say OOP is failing, most code being written today is still OOP, and I suspect that this will continue for at least the near future.

Answer 2

Have you looked into the Microsoft Coordination and Concurrenty Runtime? It's a fairly nifty way of dealing with coroutine-like problems. I've used it to write really good, scalable servers that go multicore effortlessly. I think you'll find the CCR iterator pattern to be really interesting.

Answer 3

I would say that you are starting from the wrong assumption. Is OOP failing? I disagree, based on the blizzard of OOP related traffic (often specific to threading) here.

Multithreading your code is orthogonal to any type of programming but parallel programming, which enables code obeying certain strictures automatically to run thread-safe. It's just as easy to write bad multithreaded programs using functional programming constructs as using any other choice you might make.

The problem with developing code for multicore systems is not that OOP does not extend, but that writing thread-safe code is inherently more difficult than writing single-threaded code, which is hard enough in and of itself.

Answer 4

the real problem with developing for mutlicore chips is nothing to do with the actual techniques of multi-tasking (isolated memory, task based etc), but more to do with the implementation of the threading model in the OS?

That's false. The OS works fine. The OS threading model works fine. Evidence: The OS works really well.

The "problem" with multi-threaded applications is the standard problem all software has:

• Data Structures

• Algorithms

When working in a threaded environment, you must actually design the updates and memory writes carefully to prevent race conditions that cause out-of-order writes to memory. And that's just hard. Most folks don't consider locking and mutable shared data structures carefully enough.

Read this: http://www.wilsonmar.com/1threads.htm. It's hard and some people get parts of it wrong. To me, the issue seems to be that a lot of people who are able to type code like to think they're capable of designing multi-threaded applications. Perhaps too many people are messing with multi-threaded applications when they shouldn't be.

Multi-threaded application design complexity is exacerbated by the fact that the Intel processor chip has no complete, formal, precise definition for memory write ordering.

Read this: http://moscova.inria.fr/~zappa/readings/cacm10.pdf Very important stuff on what threading is made more complex by the Intel processor family.

And, optimizing compilers make this write ordering problem yet more complex.

If you do Functional Programming with immutable data structures, optimizations of memory writes may be simplified leading to better performance.

Most of the time, most programs can be broken into concurrent processes using ordinary OS pipelines. The rest of the time, a simple message queue to pass work through a pipeline-like structure gets to a high level of concurrency with no design complexity. Why? No shared mutable data structures.