Threads simulated in software are a kludge to better utilize current processor and operating system architectures. In time machines where the parallelism is handled in hardware will be more widely available and the threading will be transparent and highly efficient.

Joe Wilson wrote:
Threads are very much in the C tradition - minimalistic.
If you code in C you must know what you're doing anyway. C is by no means a high level or safe language.

But until an automatically parallelizing safe language with good performance becomes popular - this is what we got. You just have to rely on simple conventions to minimize the risks.

--- Michael Scharf <[EMAIL PROTECTED]> wrote:

Why Threads Are A Bad Idea:
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

From the article:
  "Threads are a seemingly straightforward adaptation of the
  dominant sequential model of computation to concurrent
  systems. Languages require little or no syntactic changes to
  support threads, and operating systems and architectures
  have evolved to efficiently support them. Many technologists
  are pushing for increased use of multithreading in software
  in order to take advantage of the predicted increases in
  parallelism in computer architectures. In this paper, I
  argue that this is not a good idea. Although threads seem to
  be a small step from sequential computation, in fact, they
  represent a huge step. They discard the most essential and
  appealing properties of sequential computation:
  understandability, predictability, and determinism. Threads,
  as a model of computation, are wildly nondeterministic, and
  the job of the programmer becomes one of pruning that
  nondeterminism. Although many research techniques improve
  the model by offering more effective pruning, I argue that
  this is approaching the problem backwards. Rather than
  pruning nondeterminism, we should build from essentially
  deterministic, composable components. Nondeterminism should
  be explicitly and judiciously introduced where needed,
  rather than removed where not needed. The consequences of
  this principle are profound. I argue for the development of
  concurrent coordination languages based on sound, composable
  formalisms. I believe that such languages will yield much
  more reliable, and more concurrent programs."




      
____________________________________________________________________________________
Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/

-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------



-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------

Reply via email to