August 20, 2004
"clayasaurus" <clayasaurus@gmail.com> wrote in message news:cg4t06$9ns$2@digitaldaemon.com...
> Matthew wrote:
> > "clayasaurus" <clayasaurus@gmail.com> wrote in message news:cg3vc7$2t8d$1@digitaldaemon.com...
> >
> >>Walter wrote:
> >>
> >>>Lots more bug fixes. Added special 'length' inside array [ ]'s.
> >>>
> >>>http://www.digitalmars.com/d/changelog.html
> >>>
> >>>
> >>
> >>Walter, have you got std.loader compiled into phobos on linux?
> >
> >
> > Good question.
> >
> > btw, I'm going to bite the bullet next week and revisit std.loader. I don't know whether I can resurrect it from its current ignominy, or whether a total reimplementation (keeping interface, of course, if at all poss) will be called
for.
> >
> > I do know that it's had lots of complaints and that, even though it was born out of wedlock, I still need to take my responsibilities seriously.
> >
> > Colin the Code Cassanova
> >
> >
>
> I just checked and loader.o is still missing from libphobos.a on linux.
> Surely it would only take a few seconds of Walter's time to add it?
> Just change version(Linux) to version(linux).

Indeed.  Let's hope he does so. :-)


August 20, 2004
"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg4b8t$1pd$2@digitaldaemon.com...
> Question: what's the purpose of using "volatile" in various places. Since,
AFAIK, D's volatile speaks to intra-thread
> memory coherence, and do not cross-thread contention, aren't these
superfluous? Or have you come across some secret
> wisdom? (If so, send it to me quickly, via the secret T1!)

D's volatile has essentially nothing in common with C's, and everything to do with helping with writing multithreaded apps. I learned about it from Scott Meyer's talk on multithreading. As I recall, it was about preventing the compiler from moving loads and stores across locks. C++ has no such guarantee, although C++ optimizers in reality respect the locks. This is the modern understanding of volatile, and both Java and C# have altered their definitions of volatile to suit as well.


August 20, 2004
In article <cg4qog$8oe$1@digitaldaemon.com>, Ben Hinkle says...
>
>
>> 2.0. BTW, are you following Andrei A's thread on adding lock-free concurrent containers to C++? It's a great read in comp.lang.c++.moderated under the thread "Multithreaded programming: is the C++ standardization committee listening?"
>
>Interesting. That 64-bit CAS posting I made on digitalmars.D.bugs was in support of implementing two very cool concurrent data structures "dualqueue":
> http://www.cs.rochester.edu/~scott/papers/2004_DISC_dual_DS.pdf
>"obstruction-free circular array":
> http://www.cs.brown.edu/people/mph/HerlihyLM03/main.pdf
>
>coming to MinTL soon...

Neat stuff Ben.  Here's something that'll help if you haven't done this already.
(All apologies if you're already this up-to-speed with assembler) :)

I read through both these papers, and all I could think was: boy does this algorithm "cheat"!  It accomplishes lockless syncronization by exploiting the Compare-and-Swap atomic instruction that is present on Sparc workstations.

That's great and all, but what about us guys on x86?!?  Well, I did some sniffng around and dug up the "cmpxchg" ASM instruction.

http://members.tripod.com/~oldboard/assembly/cmpxchg.html

A concrete use of the instruction (see "compare_and_swap" function): http://www.cs.cornell.edu/courses/cs414/2001SP/minithread_md.c

This should make your implementation a little easier to write.

- Pragma


August 20, 2004
In article <cg412i$2tt9$1@digitaldaemon.com>, Matthew says...
>
>And if that's the case, then what about allowing the Python like syntax
>
>    int l = length(x); // Equivalent to int l = x.length;
>
>I'm not proposing this last bit, mind, just interested in hearing opinions on the matter.

D already supports this in reverse for arrays.  ie. length(T[] x) can be called as: length(x) or x.length.  Since this is the case, and assuming it hasn't already been done, it would be nice to expose the default parameters as D functions.  So we could call sizeof(x), length(x), etc.  By the same token, it would be nice to have this be consistent for all primitive types rather than just for array types.


Sean


August 20, 2004
In article <cg412k$2tt9$3@digitaldaemon.com>, Matthew says...
>
>"Walter" <newshound@digitalmars.com> wrote in message news:cg40au$2thv$4@digitaldaemon.com...
>>
>> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg3usm$2t04$1@digitaldaemon.com...
>> > >Added special 'length' inside array [ ]'s.
>> >
>> > Excellent. I really can't imagine this causing more than a very few
>> faltering steps for each developer, and a
>> > considerable, albiet sugary, syntactic simplification.
>> >
>> > Now, how do I go about raising the issue of D providing thread-agnostic
>> implicit reg-exp, a la Perl and Ruby?
>> >
>> > (I'm not kidding!)
>>
>> 2.0. BTW, are you following Andrei A's thread on adding lock-free concurrent containers to C++? It's a great read in comp.lang.c++.moderated under the thread "Multithreaded programming: is the C++ standardization committee listening?"
>
>No. Checking out ...
>
>Sounds like Andrei's demanding for C++ what I've said to you several times that we _could_ achieve for D (given that I share the view with some of the respondents that it's not possible/practicable for C++).
>
>Atomic ops, lock-free containers, etc. etc. We can do it. (But maybe this has to be 2.0 stuff.)

It's been a while since I checked that thread--thanks for the reminder, Walter.

I think D already has laid some decent groundwork for this with the revised volatile semantics, etc.  It would be logical to extend this to support the things that Andrei mentions, though I expect that much of this might not make it in until 2.0.

>(btw, if doing this made D lose some of the odd little platforms it might conceivably be ported to, I believe that would be a worthy pact, since this would be one area in which D would be manifestly superior to C++. Has that got your juices flowing ???)

Heck yes.  It remains to be seen how much of Boost.Threads makes it into C++ 0x, but even that is just a collection of library routines rather than native language support.  Between Unicode support and multithreading, D has a lot going for it over C++.


Sean


August 20, 2004
In article <cg4802$30v7$1@digitaldaemon.com>, Walter says...
>
>I've always been interested in support for threading, that's why the synchronize primitives are there, as well as the volatile statement. I'm not sure what else needs to happen in the core language, isn't the rest mostly a library issue?

Probably.  Though it might be nice to formalize hooks for library writers to manipulate the built-in synchronization blocks.  Also, there may be some advantage to having language support for condvars, though I haven't thought enough about this to know whether merely adding a new attribute would be sufficient.


Sean


August 20, 2004
"pragma" <EricAnderton at yahoo dot compragma_member@pathlink.com> wrote in message news:cg5dhk$i4c$1@digitaldaemon.com...
> In article <cg4qog$8oe$1@digitaldaemon.com>, Ben Hinkle says...
> >
> >
> >> 2.0. BTW, are you following Andrei A's thread on adding lock-free concurrent containers to C++? It's a great read in
comp.lang.c++.moderated
> >> under the thread "Multithreaded programming: is the C++ standardization committee listening?"
> >
> >Interesting. That 64-bit CAS posting I made on digitalmars.D.bugs was in support of implementing two very cool concurrent data structures "dualqueue":
> > http://www.cs.rochester.edu/~scott/papers/2004_DISC_dual_DS.pdf
> >"obstruction-free circular array":
> > http://www.cs.brown.edu/people/mph/HerlihyLM03/main.pdf
> >
> >coming to MinTL soon...
>
> Neat stuff Ben.  Here's something that'll help if you haven't done this
already.
> (All apologies if you're already this up-to-speed with assembler) :)
>
> I read through both these papers, and all I could think was: boy does this algorithm "cheat"!  It accomplishes lockless syncronization by exploiting
the
> Compare-and-Swap atomic instruction that is present on Sparc workstations.
>
> That's great and all, but what about us guys on x86?!?  Well, I did some
sniffng
> around and dug up the "cmpxchg" ASM instruction.
>
> http://members.tripod.com/~oldboard/assembly/cmpxchg.html
>
> A concrete use of the instruction (see "compare_and_swap" function): http://www.cs.cornell.edu/courses/cs414/2001SP/minithread_md.c
>
> This should make your implementation a little easier to write.
>
> - Pragma
>
>

Yeah - it seems like the two work-horses of the latest concurrent research are cmpxchg and cmpxchg8b (or whatever the equivalent is on a particular processor). There are some pretty nasty hacks around memory management, though, in one of those papers. It maintains a thread-specific heap by aligning the bottom of the stack and whacking off the bottom bits of the stack pointer whenever it needs to start looking for a free node. Talk about cheating!


August 20, 2004
"Matthew"  wrote ...
> I don't think we're going to be able to keep it in the same format for
DTL, though. If you don't mind, I'd rather keep
> the container implementations as consistent as possible, in terms of
layout, etc., so I'd be looking to reformat it
> considerably.
>
> Obviously there'll be deeper changes as well, such as templatisation, and
incorporation of the composable range
> transformations/filters.

Sure ... edit with aplomb  <g>


> Question: what's the purpose of using "volatile" in various places. Since,
AFAIK, D's volatile speaks to intra-thread
> memory coherence, and do not cross-thread contention, aren't these
superfluous? Or have you come across some secret
> wisdom? (If so, send it to me quickly, via the secret T1!)

That's the difference between the Java/C++ and D implementation. The former tag the variable itself, while D tags the usage. I think the D approach to the "memory-barrier" thing is the 'correct' one, but it may lead to obtuse and hard-to-find bugs. For instance, you have to manually and carefully add the volatile tag to each usage, rather than the compiler doing it for you (in the Java/C++ case). D, however, gives you more flexibility and control over how/where the barrier is applied. I think that's accurate ... someone please correct me if I'm wrong.


>
> Matthew
>
> "antiAlias" <fu@bar.com> wrote in message
news:cg48q9$ma$1@digitaldaemon.com...
> > No problem. Just pull it out of the (browser enabled) dsource.org
> > repository. The documentation needs a wee bit of attention :~)
> >
> > Let's share updates (on that module) until we get some resolution on how
to
> > easily resolve multiple interdependent libraries ...
> >
> >
> > "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg42kq$2ubh$1@digitaldaemon.com...
> > >
> > > "antiAlias" <fu@bar.com> wrote in message
> > news:cg41s8$2u61$1@digitaldaemon.com...
> > > > Walter" <newshound@digitalmars.com> wrote in message
> > > > > 2.0. BTW, are you following Andrei A's thread on adding lock-free
> > > > concurrent
> > > > > containers to C++? It's a great read in comp.lang.c++.moderated
under
> > the
> > > > > thread "Multithreaded programming: is the C++ standardization
> > committee
> > > > > listening?"
> > > >
> > > > About time too! On that note, mango.cache has a port of Doug Lea's latest-and-greatest concurrent HashMap. Nice,clean, concise bit of
code,
> > > > configurable (contention-level) and very efficient: no read-locks at
> > all.
> > > > Also has foreach() support. I suggest this migrate into one of the
> > container
> > > > libs rather than slumbering quietly within Mango.
> > >
> > > We'll get that one into DTL, if you don't mind. :)
> > >
> > >
> >
> >
>
>


August 20, 2004
"antiAlias" <fu@bar.com> wrote in message news:cg5i6n$l3k$1@digitaldaemon.com...
> That's the difference between the Java/C++ and D implementation. The
former
> tag the variable itself, while D tags the usage. I think the D approach to the "memory-barrier" thing is the 'correct' one, but it may lead to obtuse and hard-to-find bugs. For instance, you have to manually and carefully
add
> the volatile tag to each usage, rather than the compiler doing it for you (in the Java/C++ case). D, however, gives you more flexibility and control over how/where the barrier is applied. I think that's accurate ... someone please correct me if I'm wrong.

I think you've got it right.


August 20, 2004
awesome idea :-)
Matthew wrote:
> "Vathix" <vathixSpamFix@dprogramming.com> wrote in message news:cg3trp$2s1u$1@digitaldaemon.com...
> 
>>>Added special 'length' inside array [ ]'s.
>>>
>>
>>I think it's pretty cool, but might cause logic bugs. I'm just glad I've
>>been lazy in naming my variables len instead of length. Perhaps it should be
>>illegal to name something length, and just allow classes/structs/unions to
>>have an opLength() ? It would also be helpful for people porting from
>>another language. length is a pretty popular name.
> 
> 
> At first I thought yuck. But mere seconds later, I think Yes!
> 
> Please add me onto this soon-to-huge list of Yeah-sayers
> 
> 
>