Question for software engineering pros

[Cymric]

Quite recently (I forget where and when, might have been on this forum) I began to wonder what the Next Big Thing in software engineering is going to be. We've had quite a lot of experience with OOP now, to the point where there are already plenty of books which can comfortably write about the good and the bad of it---and not just spew marketing hype.

I can guess that threading and parallelisation are going to be quite important topics, now that the big CPU vendors are slowly inching towards multiple (quite possibly vectorised) cores on a single chip. Quite a number of people have pointed out that sticking a second core on a die is not a recipe for double performance, you need to be intelligent about it. (I recall Hammer pointing out, in his own informative if a little terse way, that vectorised GFX-chips are very sensitive to their drivers; so sensitive that nVidia abandoned their attempts at selling them.)

But are there other things which are currently just below the horizon?

[Cymric]

@Karlos:

You seem to like your Locks, Semaphores, Threads and what-not pretty much. Have you ever looked at this link? It's the most comprehensive tutorial on those techniques I know and contains tons of do's and dont's.

[Cymric]

@bloodline:

That's an interesting suggestion. However, for C those extensions already exist: do a Google search for 'Earth' and 'threaded C'.

However, I don't think it is wise to include multithreading support in the core language just like that. Threading is extremely dependent on the OS itself, and while most systems nowadays support POSIX-type threads, there are tons of little changes and additions in each OS. Plus you must be wary of the difference between kernel space threads and user space specimens. Some systems have just one type, the others mix them at will. Various system resources may be shared differently and thus have different visibility depending on what system you run the code. There are so many tiny quirks that I doubt adding threading support to a low-level language like C or C++ will result in something useful since most functionality will be moved to the runtime system anyway.

It's akin to neither C nor C++ offering a good, standard memory management package. I know some people prefer to clean up after themselves, but for rapid prototyping, such details are really not something you want to be bothered with. (It is also the reason why we have so many insecure systems, details and deadlines usually don't mix ;-).)