There’s another way to think about the issue you call “inherent concurrency”. Typical server jobs (such as database systems) are often measured by total throughput (eg transactions per second) whereas many client applications are sensitive to response time in order to support interactive behavior. This difference can lead to very different strategies when considering how to extract parallel performance.

Also, you point out that locks are error-prone, but there is another serious problem with locks – programming with explicit locks can often serialize a program, sometimes in subtle ways. This results in losing the benefits of parallelism as threads line up to acquire the lock one at a time.

Another alternative to explicit-lock programming, in addition to the transactional model you describe, is the “hyperobject” concept that our company (Cilk Arts) describes at http://www.cilk.com/multicore-products/cilk-hyperobjects.

great work.

On the server-side for transaction true the server does automatically use the processing power when multiple users are accessing it.

The reality how many people write applications that care about client-side performance like GIS, Game Development, Graphics packages? The sad fact is most of us write bespoke business applications.

In finance the biggest problem is long batch runs that can be solved by using concurrency. Nobody really cares if it takes a few seconds for a transaction to go through, but they do start caring when the nightly process runs contract by contract and starts to creap into the start of the new working day.

http://research.microsoft.com/~simonpj/papers/stm/#beautiful

On that basis the most complex an app can be is set to about 0.5 seconds of processing (web app). What a frightening thought.

Scalability in data is still a big problem, the relational database is in need of a lot more parrallel processing. We’re not done yet needing faster algorithms, we could certainly use them.

you are right regarding the much greater difficulties in making client code concurrent. You cite “library” or “language” approaches to the problem.

I think that a “pattern” approach would also be very much desirable. There are a few common ways of parallelizing sequential code. Maybe starting to collect these approaches from practical experiences, abstracting patterns, and publishing them is the most correct approach at this stage.

Can you cite anybody that is following this approach?