在 Thu, 24 Apr 2008 21:46:06 +0800，Christopher Wright <dhasenan@gmail.com> 写道:

> davidl wrote:
>> 在 Thu, 24 Apr 2008 14:35:40 +0800，Walter Bright <newshound1@digitalmars.com> 写道:
>>
>>> http://www.digitalmars.com/d/1.0/changelog.html
>>> http://ftp.digitalmars.com/dmd.1.029.zip
>>>
>>> This starts laying the foundation for multiprogramming support:
>>>
>>> http://www.digitalmars.com/d/2.0/changelog.html
>>> http://ftp.digitalmars.com/dmd.2.013.zip
>>  nice opDot feature in 2.0.
>>  Though sometimes on windows, people need some unchecked opDot calling.
>
> You mean, there are situations in which you want to be sure that you're using opDot and some in which you want to be sure you're not? The former, you can just write "foo.opDot.x", but not the latter.
>
> I wonder how this works with overloads, too.
>
>> Consider ActiveX stuff.
>>  People are not always want to have to create their own bindings... especially for some R&D test.
>>  myActiveXObject.Some_Func_Can_be_Determinated_at_runtime();
>> myActiveXObject.Some_Compile_Time_Unchecked_Var = 3;
>>  with current opDot, we are still not able to do so.
>>  Yet current opDot looks cleaner.
>>  I feel it's kinda dilemma...
>
> You mean, some sort of dynamic function call system? Like opDot(char[]) so you can do:
> auto x = foo.bar; // calls foo.opDot("bar");

opDot(char[]) is what all I meant


-- 
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/

Sean Kelly Wrote:

> == Quote from Kevin Bealer (kevinbealer@gmail.com)'s article
> > Sean Kelly Wrote:
> > > == Quote from Walter Bright (newshound1@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

Steven Schveighoffer wrote:
> "Walter Bright" wrote
>> Sean Kelly wrote:
>>> From my understanding, the problem with doing this via inline assembler is
>>> that some compilers can actually optimize inline assembler, leaving no truly
>>> portable way to do this in language.  This issue has come up on
>>> comp.programming.threads in the past, but I don't remember whether there
>>> was any resolution insofar as C++ is concerned.
>> There's always a way to do it, even if you have to write an external function and link it in. I still don't believe memory mapped register access justifies adding complex language features.
> 
> Who's adding?  We already have it and it works.

No, we don't. There's volatile in C, which is being abandoned as a mess and C++ is going with a new type, atomic. There's the volatile statement in D, which is unimplemented.


> If volatile was not already a solved problem, I'd say yeah, sure it might be more trouble than it's worth.  But to remove it from the language seems unnecessary to me.

I don't agree that it's a solved problem.

> 
> I was just asking for justification for *removing* it, not justification for having it :)
> 
> -Steve 
> 
> 

0ffh wrote:
> Just out of curiosity, which approach would you recommend to ensure
> that a variable which is updated from an interrupt service routine
> (and, implicitly, any other thread) will be read from common memory
> and not cached in a register?
> I know there are a few, but which would you recommend?
> I think ensuring that memory access happens at every variable access
> is a straightforward solution (and a good one, if access is atomar).

I suggest wrapping it in a mutex.

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:furjvd$1hlm$1@digitalmars.com...
> Steven Schveighoffer wrote:
>> "Walter Bright" wrote
>>> Sean Kelly wrote:
>>>> From my understanding, the problem with doing this via inline assembler
>>>> is
>>>> that some compilers can actually optimize inline assembler, leaving no
>>>> truly
>>>> portable way to do this in language.  This issue has come up on
>>>> comp.programming.threads in the past, but I don't remember whether
>>>> there
>>>> was any resolution insofar as C++ is concerned.
>>> There's always a way to do it, even if you have to write an external function and link it in. I still don't believe memory mapped register access justifies adding complex language features.
>>
>> Who's adding?  We already have it and it works.
>
> No, we don't. There's volatile in C, which is being abandoned as a mess and C++ is going with a new type, atomic. There's the volatile statement in D, which is unimplemented.

Wait, you mean the volatile statement was never even implemented, even in D1?

Where is this mentioned, anywhere?

Jarrett Billingsley wrote:
> Wait, you mean the volatile statement was never even implemented, even in D1?

All it did was apply C's volatile semantics to the enclosed statements, which is really not good enough for multithreading.

> Where is this mentioned, anywhere? 

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:fut4bg$30a2$1@digitalmars.com...
> Jarrett Billingsley wrote:
>> Wait, you mean the volatile statement was never even implemented, even in D1?
>
> All it did was apply C's volatile semantics to the enclosed statements, which is really not good enough for multithreading.

No, it's not.  But it's good enough for system programming, when you have things like memory-mapped registers and memory locations that change on interrupts.  Relying on ASM or other languages to do something so fundamental in a language that's _meant_ to be a system programming language seems like a terrible omission.

Jarrett Billingsley wrote:
> No, it's not.  But it's good enough for system programming, when you have things like memory-mapped registers and memory locations that change on interrupts.  Relying on ASM or other languages to do something so fundamental in a language that's _meant_ to be a system programming language seems like a terrible omission. 

I don't agree. I've done ISRs and memory mapped I/O. The actual piece of code that accessed the data that way formed a miniscule part of the program, even on programs that were completely interrupt driven (like I wrote an ASCII terminal program). Those are well served by two lines of inline asm or a compiler builtin PEEK and POKE function.

Building a whole volatile subsystem into the type system for that is a huge waste of resources.

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> 0ffh wrote:
> > Just out of curiosity, which approach would you recommend to ensure
> > that a variable which is updated from an interrupt service routine
> > (and, implicitly, any other thread) will be read from common memory
> > and not cached in a register?
> > I know there are a few, but which would you recommend?
> > I think ensuring that memory access happens at every variable access
> > is a straightforward solution (and a good one, if access is atomar).
> I suggest wrapping it in a mutex.

I suppose the obvious question here is: what if I want to create a mutex in D?


Sean

== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> Building a whole volatile subsystem into the type system for that is a huge waste of resources.

I thought volatile was a statement in D, not a type?


Sean