[dmd-concurrency] draft 4

[Andrei Alexandrescu]

I totally agree about the introduction. I was also thinking to prepend 
some text to the headless chapter intro that would read something like this:

=======================
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Concurrency}
\label{ch:concurrency}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Convergence of  various factors  in the hardware  industry has  led to
qualitative  changes  in the  way  we  are  able to  access  computing
resources,  which in  turn prompts  profound  changes in  the ways  we
approach   computing    and   in   the    language   abstractions   we
use.  Concurrency is now  virtually everywhere,  and it  is software's
responsibility to tap into it.

Although the software  industry as a whole does  not have yet ultimate
responses  to   the  challenges  brought  about   by  the  concurrency
revolution,  \dee's  youth  allowed  its  creators  to  make  informed
decisions  regarding  concurrency without  being  tied  down by  large
legacy  code  bases.  A  major  break  with  the  mold  of  concurrent
imperative  languages is  that \dee  does not  foster sharing  of data
between threads; by default, concurrent threads are virtually isolated
by language mechanisms.  Data sharing is allowed but  only in limited,
controlled ways that offer the  compiler the ability to provide strong
global guarantees.

At the same time, \dee remains at heart a system  programming language
so  it  does  allow  you  to  use a  variety  of  low-level,  maverick
approaches to concurrency. (Some of these mechanisms are not, however,
allowed in safe programs.)

In brief, here's how \dee's concurrency offering is layered:

\begin{itemize*}
\item  The  flagship approach  to  concurrency  is  by using  isolated
   threads or processes that  communicate via messages.  This paradigm,
   known as \emph{message passing},  leads to safe and modular programs
   that are easy to understand and maintain. A variety of languages and
   libraries  have  used  message passing  successfully.   Historically
   message  passing has  been slower  than approaches  based  on memory
   sharing---which  explains why  it was  not  unanimosly adopted---but
   that trend  underwent a  definite and lasting  reversal.  Concurrent
   \dee programs are  encouraged to use message passing  and benefit of
   extensive infrastructure support.
\item \dee  also provides support for  old-style synchronization based
   on critical sections protected  by mutexes and event variables. This
   approach  to  concurrency  has   since  recently  come  under  heavy
   criticism  because of  its  failure  to scale  well  to today's  and
   tomorrow's  highly  parallel  architectures.   \dee  imposes  strict
   control  over   data  sharing,   which  in  turn   curbs  lock-based
   programming  styles.   Such restrictions  may  seem  quite harsh  at
   first, but they  cure lock-based code of its  worst enemy: low-level
   data races.
\item In  the tradition of  system-level languages, \dee  programs not
   marked as \cc{\@safe} may use casts to obtain hot, bubbly, unchecked
   data  sharing.  The  correctness of  such programs  becomes entirely
   your responsibility, and is often system-dependent.
\item If  that level of control  is insufficient for you,  you can use
   @asm@   statements   for   ultimate   control  of   your   machine's
   resources. To go  any lower level than that,  you'd need a miniature
   soldering iron and a very, very steady hand.
\end{itemize*}

Before getting into the thick of  the topics above, let's take a brief
detour  in  order to  gain  a  better  understanding of  the  hardware
developments that have shaken our world.

\section{Concurrentgate}

When it comes to concurrency, we are living the proverbial interesting
times more than  ever before. ...
==============================

Works?


Andrei

Steve Schveighoffer wrote:
> This all looks very cool for message passing.
> 
> I'm still more interested in how shared turns out, message passing seems to be a very straightforward problem with a very straightforward solution.  Also, having never really used a language with builtin message passing or a MP library (I have implemented it several times unwittingly not knowing the pattern), I can't really add any more insightful comment except to say it does look exciting :)
> 
> A comment on the introduction, I know that the other chapters of the book don't have an initial section header, but you may want to break up this section into a brief introduction and then title this section header appropriately.  Although it is a good lesson and backs up the design choices of D, it doesn't have anything to do with D's API.  Having to read 6 pages of history before reading anything about D is puzzling.  The header "A brief history of data sharing"  before the whole thing would cue uninterested readers to jump to the meaty parts.
> 
> Pretend your a person learning D, and you already know that message passing is the best, having dealt with some message passing library (or language that supports it).  You don't want to read through a history lesson confirming what you already know, you just want to answer the question "how does D do concurrency?"  Basically, I think you should explicitly identify the "how" and "why" parts, preferably putting some of the "how" first.
> 
> -Steve
> 
> 
> 
>       
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency