DMD 1.029 and 2.013 releases

[Sean Kelly]

== Quote from Kevin Bealer (kevinbealer at gmail.com)'s article
> Sean Kelly Wrote:
> > == Quote from Walter Bright (newshound1 at digitalmars.com)'s article
> > > Steven Schveighoffer wrote:
> > > > You can sort of work around it by wrapping the previously volatile statement
> > > > in a function, but it seems like having volatile doesn't really hurt
> > > > anything.  I'm curious to know why it was so bad that it was worth
> > > > removing...
> > > Because after listening in while experts debated how to do write
> > > multithreaded code safely, it became pretty clear that the chances of
> > > using volatile statements correctly is very small, even for experts.
> > > It's the wrong approach.
> >
> > Every tool can be mis-used with insufficient understanding.  Look at shared-
> > memory multiprogramming for instance.  It's quite easy and understandable
> > to share a few data structures between threads (which I'd assert is the original
> > intent anyway), but common practice among non-experts is to use mutexes
> > to protect code rather than data, and to call across threads willy-nilly.  It's
> > no wonder the commonly held belief is that multiprogramming is hard.
> >
> > Regarding lock-free programming in particular, I think it's worth pointing
> > out that leaving out support for lock-free programming in general excludes
> > an entire realm of code being written--not only library code to be ultimately
> > used by everyday programmers, but kernel code and such as well.  Look at
> > the Linux source code, for example.  As for the C++0x discussions, I feel
> > that some of the participants of the memory model discussion are experts
> > in the field and understand quite well the issues involved.
> >
> I've use a tiny amount of lock-free-like programming here and there, which is to
> say, code that uses the "compare and swap" idiom (on an IBM OS/390) for a few
> very limited purposes, and just the "atomic swap" (via a portable library).
> I was trying to do this with D a week or two back.  I wrote some inline ASM code
> using  "xchg" and "cmpxchg8b".  I was able to get xchg working (as far as I can
> tell) on DMD.  The same inline ASM code on GDC (64 bit machine) just threw a
> BUS error for some reason.  I couldn't get cmpxchg8b to do what I expected on
> either platform, but my assembly skills are weak, and my inline assembly skills
> are even weaker.  (it was my first stab at inline ASM in D).
> 1. I have no idea if my code was reasonable or did what I thought but...
> 2. there might be a gdc / dmd ASM compatability issue.
> 3. I think it would be cool if there were atomic swap and ideally, compare
>     and swap type functions in D -- one more thing we could do portably that
>     C++ has to do non-portably.
> 4. By the way these links contain public domain versions of the "swap pointers
>     atomically" code from my current work location that might be useful:
> http://www.ncbi.nlm.nih.gov/IEB/ToolBox/CPP_DOC/doxyhtml/ncbiatomic_8h-source.html
> http://www.ncbi.nlm.nih.gov/IEB/ToolBox/CPP_DOC/lxr/source/include/corelib/impl/ncbi_atomic_defs.h
> Unfortunately, it looks like they don't define the _CONDITIONALLY versions for
> the x86 or x86_64 platforms.  One of my libraries at work uses the atomic
> pointer-swapping to implement a lightweight mutex for a libraries I wrote and
> it's a big win.
> Any thoughts?  It would be neat to play with lock-free algorithms in D, especially
> since the papers I've read on the subject (Andrei's I think) say that it's much easier
> to get the simpler ones right in a garbage collected environment.

Tango (and Ares before it) has support for atomic load, store, storeIf (CAS), increment,
and decrement.  Currently, x86 is the only architecture that's truly atomic however, other
platforms fall back to using synchronized (largely because D doesn't support inline ASM
for other platforms and because no one has asked for other platforms to be supported).
The API docs are here:

http://www.dsource.org/projects/tango/docs/current/tango.core.Atomic.html

And this is the source file:

http://www.dsource.org/projects/tango/browser/trunk/tango/core/Atomic.d

The unit tests all pass with DMD and I /think/ they pass with GDC as well, but I haven't
verified this personally.  Also, the docs above are a bit misleading in that increment and
decrement operations are actually available for the Atomic struct if T is an integer or a
pointer type.  the doc tool doesn't communicate that properly because it has issues with
"static if".  Oh, and I'd just use the default msync option unless your needs are really
specific.  The acquire/release options are a bit tricky to use properly in practice.


Sean