Discussions

Though the core of this article doesn't consider Java, the summary at Artima spins our favorite platform into the mix. The message is one that all developers need to consider: Multi-core technology is quickly becoming the norm rather than the exception.
Intel is quoted as saying that in the coming years we should expect to see desktops that have 4 to 8 cores. Furthermore, 70 percent of new desktops will be multi-core by the end of the year. All this information has to leave developers wondering just how thread-safe their code really is.
As Frank Sommers points out in his summary, there are three primary challenges to multi-core/threaded systems: parallelism or keeping the cores busy, correctness and ease of programming. Running a test 100 times may only demonstrate a problem once. It is the unpredictability of the occurrence of threading related bugs that make diagnosing and correcting them so difficult.

The second challenge is "correctness" — how to avoid race conditions, deadlocks and other bugs characteristic of multi-processor applications.

The analysis of the overall situation is that unlike other languages and platforms, Java is well-positioned to live in this new desktop environment, as threading is a core feature. Java developers also have years of experience programming on multi-processor servers. This experience has led to the development of Doug Lea's excellent concurrency library that was adopted/adapted in the latest release, JSE 5.0.
The expected consequence of this change is that performance is going to come at the cost of increased complexity. At the end of the summary, Frank asks: Will developers have trouble working with multi-core systems? Do you think Java is better suited to multi-core platforms than the alternatives?

Most Java development is done on the proverbial server side, not on desktop machines. Multi-core may be a little new for servers, but multi-processor certainly is not. Most developers writing server code have been dealing with multi-threading for a decade or more. Maybe some Swing devs haven't had to worry about it, but they are definitely a minority in the Java dev kingdom.

No offense, but swing apps have just as much threading concerns as server side apps. They're different concerns, for different reasons, but they're definitely multithreading concerns.
Basically any application that has a Cancel button must be using threads...unless it's a seriously horrible application. ;-)
Regardless...I don't think multi-core changes anything. Partially for the reasons above (i.e. it's been around in the server end for decades), but mostly because the popularity of virtual machines keeps us so far away from the hardware, that you will have little choice about how the cores handle your threads anyway.
At most, you may decide to spin off more threads than you normally would have for mutually exclusive or at least non-order dependent tasks. But I'd really question any such design that didn't have a really good reason.
As Java and C# developers, we really shouldn't be worrying about CPU cores. Leave it to the OS, driver and VM developers.
Who's to say they put all of those cores there for your application anyway? Maybe they intended to run 16 applications on their 16 core CPU.
And parallel processing is nothing new. Old mainframes (e.g. IBM ES/9000) dealt with concurrency by way of having dozens of hardwired thicknet cable plugged into the back, with a green-screen terminal at the other end of each. Do you think each user was waiting in line for the others? Nope!
Cheers,
Clinton
Cheers,
Clinton

and no matter what happens you will never stop being an opinionated !@#$%&*

Being an "opinionated !@#$%&*" doesn't mean your opinion isn't right. Being an "!@#$%&*" can make it difficult to sell your opinion though :-)
Despite the fact the Java is one or the more multi-threading friendly languages and many support libraries and frameworks (incl. J2EE) goes to great lengths to hide the details, it's far from something you can be ignorant of, if you want to label yourself as a programmer (IMNHO). Even in relatively simple and still quite common cases like creating a singleton* in a J2EE environment, you will find implementations which are not properly handling multi-threading and hierarchical classloaders.
* Yes, yours truely is aware that singletons are generally frowned upon by some :-)

Seems like some people are unwilling to deal with concurency.
I am pretty sure customer demands will emerge in problem domains that justifies utilizing as many cores as are available.
Maybe this is what is needed to expose the hacks that should never have gotten into computer science in the first place.
Being "customer/business oriented" has allways been a beard for the pansies who lacked technical skills to begin with.
Distinction between architects and developers is a recent invention that would have been unnessesary if customer/business oriented people would've just found another career better suited for their limited talents.

Being "customer/business oriented" has allways been a beard for the pansies who lacked technical skills to begin with.

Pansies or businessmen/women? I think if you try selling technology to customers that aren't technologists, you'll lose their interest right away. Being customer oriented is very important -- it basically says you'll work with them to get their project finished and working to their liking.
Distinction between architects and developers is a recent invention that would have been unnessesary if customer/business oriented people would've just found another career better suited for their limited talents.

What you've said above sounds like you find business people to be of limited / no value, however business people are quite important, especially when it comes to getting customers. If someone can write some software to automate this, then we won't ever need them again. Of course, that's never going to happen because people do business with people -- and the more customer centric one is, the better chance they have of making a sale.

About the only thing worth noting here for me is this : if programmers have to write code to 'take advantage of' multi-threaded machines, we've missed the point.
As I've been arguing with UNIX weenies for 10 years or so, I don't want to know the operating system when I program. God forbid I should know about the fucking hardware ! The more I have to know about these things, the worse off my customer is going to be.

Java and any other imperative language actually is very bad for parallelling programs.
It does not matter how good is your multi-thread library. The subject is still horrendously difficult to 99% of developers.
Also the argument that java is strong on server side does not count. Because the only programmers who write multithreaded programs are developers of servers.
Average java web developer never ever have to do any multi-thread work. All his programs run in single thread. Although server itself may instantiate many of those progras simultaniously.
Real advantage will be on the side of functional languages.
Because functional programming allows automatic parallelling of programs. So developers are abstarcted from hardware issues.
For example Parallell Haskell has only 2 operators for parallelling: par and seq.
You mark with those operators parts of code you would like to be spawned in a separate thread. And you do not care about synconization, deadlocks, concurrent access, anything.
It is taken care of for you automatically.
Or another approach - Erlang, language specificall designed for multiprocess programs. Althou not that simple as haskell in solving multiprocess isssues, it is still miles ahead of java.
I think massive move of industry to multi-core processors will dramatically change the landscape in programming.
In 10 years, functional languages will become strong rivals, if not completely overtake imperative OO languages like java or csharp.

I think massive move of industry to multi-core processors will dramatically change the landscape in programming.

In 10 years, functional languages will become strong rivals, if not completely overtake imperative OO languages like java or csharp.

I really don't think so. Application developers should not be worried about the effect of threading & multicore issues, that's the job of the OS.
IMO transparancy of written code is one of the most important criteria of maintainable software. I'm not an expert on functional languages, but as far as I can see, code written in a pure functional language doesn't look very transparent to me. For example, if I'm not mistaken functional languages don't support loops as we know them in imperative languages, they're replaced by recursion. I'm sorry, but I don't see what's transparant about that. Much more likely, there will be certain things/constructions of functional languages that imperative languages will implement (for example the closures that will be implemented in C# 3.0, or closures in Ruby).
I think that Functional Languages will influence the way we will program in the future, but just fully replacing the current imperative languages is just wishfull thinking.

if I'm not mistaken functional languages don't support loops as we know them in imperative languages, they're replaced by recursion. I'm sorry, but I don't see what's transparant about that.

It is your problem. Not nesessarily problem of all programmers.
I have no difficulties both reading and thinking a task in recursion. I'm sure i'm not unic, and everyone (including you) have the same ability. It's just means different school of programming, different training, that's all.
And business demand of utilizing all those cores will make sure that new generation of programmers are taught corect set of skills.

It is your problem. Not nesessarily problem of all programmers.I have no difficulties both reading and thinking a task in recursion. I'm sure i'm not unic, and everyone (including you) have the same ability. It's just means different school of programming, different training, that's all.

Sorry but I don't fully agree with you. I've done recursive programming myself quite a bit but I think that most people would prefer a simple loop construction instead of recursion (when it's possible). Why? Because it lies closer to 'the way' humans think about things. I don't say that recursion is bad or 'too' difficult or whatever (sometimes it makes things easier), but when I have to make a change to a program then it's a lot easier when the program is written in a way so I can 'just read' in a sequential manner what's happening. And IMO recursion doesn't lend itself very well to that. I don't think it has to do with training or ability or whatever, I think recursion tends to lean towards a more 'mathematical' way of thinking which may be ideal to describe the laws of nature..., but may not be the ideal way to describe real world behavior/rules common in business applications.

I've done recursive programming myself quite a bit but I think that most people would prefer a simple loop construction instead of recursion (when it's possible).

Agree. But we are not talking about what is "natural" to humans and what is not.
In that sence programming is unnatural thing for humans to do.
Yet we are forced to programm becasue business demands.
All i'm saying is, with multi-core cpu everywhere business will start demanding such "unnatural" thing as functional code from us, programmers.
And we will have to conform, or step aside.
Java is not helping here.

Parallelism is nothing new.
Functional languages have had decades to prove their worth in parallel environments. Haskell itself is 15 years old, and where is it? In the dusty basement of a university.
Functional languages largely failed in the real world.

In 10 years, functional languages will become strong rivals, if not completely overtake imperative OO languages like java or csharp.

I've heard the same in the early 80s, the 90s and now again.
Never ever since then have functional languages left the universities for significant utilization in commercial projects.
FL are nice for writing efficient algorithms, but they are weak for doing the grunt work in most commercial projects.
Maybe there will be some influence between them, but I think of FL more of an additional possibility for very specific problems than a replacement.
Furthermore this would be a total change of the programming paradigm. This has never happened in the history of commercial software engineering. It's evolution, not revolution that wins.

More likely, we'll see languages like Nemerle and Scala that bring at least higher order functions, but leverage existing libraries on the JVM and CLR. Not concurency-related, but for Pete's sakes, can we at least get some type inference into mainstream languages.

I've heard the same in the early 80s, the 90s and now again.
Never ever since then have functional languages left the universities for significant utilization in commercial projects.

Look at the subject of this topic. "The Impact of Multi-Core CPUs on Developers"
Did we have multi-core CPUs en masse back in 80s and 90s ?
Did we have a business demand to utilize all those multicores ?
The only multi-processor computers we had back then were servers. And ALL server-side products ARE multithreaded.
Think about it. A server product that is not multithreaded is not competitive.
And now the same requirements (being agressively multi-threaded) gonna be imposed to client side apps too.
Not just CPU hungry apps like Photoshop. But much wider set of apps.
Business will demand super-fast sorting and filtering of large sets of data, voice command and recognition real time.
Encrypting-Decrypting on the fly, and many other things.
You know how insanely difficult the current model of manual mutli-therading is. People cannot reason about non-deterministic algorits. It is too much for us (maybe ok for dozen of geniuses)
Languages that allows parallelling algoritms automatically, without involving programmer are going to be winning ticket.
And that ticket is not java.
And no, this is not for obscure, marginal, specific cases only.
This is going to be important for wide set of everyday programmers tasks.

So what? Big deal if Java is not natively fully equipped for parallel computing. Its never meant to be a special purpose parallel computing language. In fact if you did any JEE development you should know that the spec itself forbids the developer from spawning threads in the container, the developer should, ideally, never have to worry about it. The developers of the container has to worry about it, but whats the ratio of the container developers to EE developers? Your so called Era can come and go and it still won't make a difference to a big lot of us.
All this decade, the industry have been moving to abstract as much of the complexity of enterprise development as possible so all the developers have to worry about is implementing bussiness logic and not worry (or worry as little as possible) about the complexities like distributed computing, security, multi-threading. Why would we want to throw all that away and use a functional language so we can feel cool because it lets us get down and dirty with parallelization? In the event that parellization does become important to step up to the next level of computing power, all we need is another abstraction from the container , so programs pre-parallization still runs and newer programs can take advantage of the new processing power. No change in language necessary.

Why would we want to throw all that away and use a functional language

I do not understand why use of functional language is throwing away what you got :))
You can have security, and containers and all that infrastructure implemented in any FL. It is not a sole pregorative of java.
And since Intel and AMD are pushing us to multi-core, business will require programmers to utilize all that power.
Those who can - will be competitive. Those who cannot - will in worst case - loose their job, in best case - become low level "junior" programmers.

In fact if you did any JEE development you should know that the spec itself forbids the developer from spawning threads in the container..

There is now a standard way (from JSR 236/237) for the container to expose a thread factory to the application in such a way as to avoid the problems associated with "new Thread()".
Peace,
Cameron Purdy
Tangosol Coherence: The Java Data Grid

Java and any other imperative language actually is very bad for parallelling programs.It does not matter how good is your multi-thread library. The subject is still horrendously difficult to 99% of developers.

Also the argument that java is strong on server side does not count. Because the only programmers who write multithreaded programs are developers of servers.

Average java web developer never ever have to do any multi-thread work. All his programs run in single thread. Although server itself may instantiate many of those progras simultaniously.

Real advantage will be on the side of functional languages.Because functional programming allows automatic parallelling of programs. So developers are abstarcted from hardware issues.

For example Parallell Haskell has only 2 operators for parallelling: par and seq.You mark with those operators parts of code you would like to be spawned in a separate thread. And you do not care about synconization, deadlocks, concurrent access, anything.It is taken care of for you automatically.

Or another approach - Erlang, language specificall designed for multiprocess programs. Althou not that simple as haskell in solving multiprocess isssues, it is still miles ahead of java.

I think massive move of industry to multi-core processors will dramatically change the landscape in programming.

In 10 years, functional languages will become strong rivals, if not completely overtake imperative OO languages like java or csharp.

Yeah right, web developers code his program in single thread, okay, please put declare all variables as class variables for your online shopping system, okay? do you need to know if it's multithreaded or not, Mr.?
Why don't we simply look at this at the other point of view. Multicore can bring signicant positive impact to developers because developers originally develop applications on single-core CPU may now design better with multicore and make use of scheduler or thread-pool to utilize more resources available from the system to make the applications run more efficiently?
e.g. Single-core app might implement a queue for processing because it turns out to be the best performance after all metrics. Now multicore takes place and performance test shows a decrease speed of the applications, which may due to the fact that multicore CPUs have lower CPU speed; okay then take away the dependendcy from your code, add a controller and make two queues instead of one queue, see the performance. Is that too difficult for you or you just don't know how to test? I am sure that you will see significant increase of performance.
So if this is the case, why arguing so much about Java or whatsoever that is worst for programming or what? C, C++, Java, Script, VB or whatever language can make use of multicore, it just depends on your design, I strongly believe in that.
Don't you agree?!

...on Windows the latest JDKs use different locking policies depending on the number of CPUs you have?
if you develop with a single CPU and then migrate to multiple CPUs you might discover funny things with the task manager...
And: yes, having done multithreading with native libs and with java I must say I feel much safer with java and can be much more productive respect to concurrency

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.