The future of concurrent programming

[Sean Kelly]

Dave wrote:
> 
> How will the new Intel chip architecture really drastically change that? 
> I recently read an article that many server applications are already 
> "close to ideally suited" to the new CPU architectures, and "should 
> immediately benefit" from them.

Most of them are.  I think the problem will be more with user apps, 
particularly games.

> (If they can "immediately benefit" from the multi-core designs, then 
> it's not a leap to suppose that these "old" techniques must still hold a 
> good deal of merit. Why re-invent the wheel?).

Because the traditional means of multi-threading will not scale well to 
systems with a large number of CPUs (in my opinion).  By large I mean at 
least 16, which people at Intel have said we'll be using within a few 
years.  That doesn't give software developers much lead time to figure 
out how to easily use all that hardware.

> What I think will need to change for the most part will be how _some_ 
> "fat client" applications are developed, but that is becoming less 
> relevant in this era of "thin-client" computing. IIS, Apache, Oracle, 
> SQL Server and the rest take care of most of the concurrent operation 
> worries for us <g> OTOH, maybe multi-core becoming available on a 
> typical client will create a resurgence of demand for "fat-client".

How many "thin client" applications do you use?  I don't use any, unless 
you count web forums.  If the "thin client" idea invades the desktop I 
suspect it will be as common for desktops to be running both the client 
and the server as it will to run only the client with a remote server. 
And that still leaves out games, which have been driving personal 
computer development for almost 20 years.  I suppose that means I think 
"fat clients" are the more likely scenario.


Sean