• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

When is threading appropriate?

 
author
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here are the slides from a talk by John K. Ousterhout done a number of years ago. This thinking influenced me back then and helped my develop an interest in alternate forms of concurrency aside from threading such as the process model found within Erlang. Threads are extremely suitable in a number of cases, that number of cases however, is smaller than many people think. Take a look:

http://home.pacbell.net/ouster/threads.pdf
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Fifteen years later, and it still rings true. I've been reading other opinions lately which say basically "Threading is hard, so let's have the smart people who can handle it properly package it or encapsulate it somehow, so that ordinary programmers can use it without falling into all of those tar pits."

I think there's been some progress in this direction, but not much. I rewrote some of my code just the other day to use classes from the java.util.concurrent package, which simplified it a bit, but the tar pits were still in plain view. I think that whatever threading abstractions the experts come up with are going to be leaky for quite a while yet.
 
Bartender
Posts: 4179
22
IntelliJ IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But at the same time, the benefits of multi-threading is increasing as hardware is more capable in support for more simultaneous tasks (multiple cores are the norm now, not the exception. And memory isn't a limitation as much either.) So were-as the problems persist, there is greater potential for benefit and so more demand. I think something major needs to change in Java in this respect...
 
Martin Logan
author
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would say that the benefit lies in the being able express concurrency oriented solutions and to properly exploit the parallelism of new hardware. The threading abstraction, fundamentally the shared memory approach, is what needs to change for the vast majority of cases to truly allow the programming community at large to benefit. With process based concurrency leveraging multicores is well within the reach of any intermediate level programmer. Erlang is a good example of this.

The other nice aspect of getting rid of shared memory is that distribution becomes more simple. The syntax for communicating across machines does not have to change from that used to communicate locally. This is called location transparency and can't be achieved with shared memory, because of course, memory can't be shared over a network, only copied.

Martin
 
I am Arthur, King of the Britons. And this is a tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic