DMD 1.029 and 2.013 releases

[Kevin Bealer]

Sean Kelly Wrote:

> == 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

Thanks Sean -- By now I should know to just check Tango!  (It's also probably
a good way for me to learn the D inline assembly techniques.)

Kevin