[dmd-concurrency] draft 4

[Sean Kelly]

You'll probably have to edit the opening of the history section to get it to flow right, but this is a much cleaner approach to the chapter.

On Jan 12, 2010, at 11:45 AM, Andrei Alexandrescu wrote:

> 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
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency