in the future: Will languages be developed to accomodate specifically for multi-core systems? If so, how?

Any languages that supports multiple threads (which is most of the major ones) can already accommodate multi-core/multi-processor systems. The catch is that it is up to the programmer to implement concurrency.

There are languages that are inherently parallel. For example functional languages (Lisp, Haskell) and actor-model languages (Erlang, Axum).

Both Google and Microsoft announced languages, Go and Axum respectively, that were specifically designed for concurrency in 2009.

So I guess the answer to your question is Yes

I'd read about issues, like concurrency. But I wondered if maybe more would go into it...

I wonder if automatic-concurrency will be a feature built-in to certain languages, while others will be totally bereft. This could perhaps become the new, "this language has automatic garbage collection and this one doesn't" comparison/debate. no?

Originally Posted by Lashtal

I wonder if automatic-concurrency will be a feature built-in to certain languages, while others will be totally bereft.

As I pointed out, some languages are inherently concurrent. Others support concurrency, but it has to be explicitly coded to be concurrent. Some languages don't support concurrency at all.

Originally Posted by Lashtal

This could perhaps become the new, "this language has automatic garbage collection and this one doesn't" comparison/debate. no?

Garbage collected vs non-garbage collected is about performance. For embedded systems or performance critical applications you don't want a garbage collector kicking in at just any time. Languages like Java don't allow the coder to specify when garbage collection should occur, or maybe more importantly, not occur (actually I believe Java allows you to 'suggest' when to do garbage collection). However, in general, features like garbage collection are more 'affordable' than in the past.

Concurrency is about performance as well, but the question you have to ask yourself is 'Is it useful to divide a single task between multiple processors?'. Some tasks are strictly sequential and cannot be done concurrently (ie function b needs the result of function a before it can do any work). Other tasks aren't demanding enough to warrant concurrency, and the overhead of implementing concurrency may reduce overall performance.

Languages that support SMP (Symmetrical Multiple Processors) have been around for many years. Back in the "dark ages" of Unix. (Solaris & HP-UX) multiple processors was the order of the day.


It's simply M$ Windows (as usual) software that needs to catch up

Originally Posted by chrishirst

It's simply M$ Windows (as usual) software that needs to catch up

It's not the operating system, it's the software running on the operating system. Windows can delegate tasks between processors just fine. What it can't do is take some software that was coded to use a single thread of execution and make it utilize multiple processors.

Yep. It wasn't the OS I was really referring to (should have made that clearer). The Windows OS has been SMP capable since NT3.51 and Win95 of course, though it did have some "stability" issues there.
I should have said software FOR the windows OS

Many software developers still use the "apartment" threading model because it lets the OS handle the threads rather than them having to be aware of synching the worker threads and the UI threads.

http://gsraj.tripod.com/com/com_threading.html

Maybe it's the Windows ME and Vista debacles that makes developers wary of going all out multi-threaded.