"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.)

I'm interested right now in whether reading that thread's made you more or less interested in native threading support for D than you were the last time we discussed it?

(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 ???)

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.

"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. :)

"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg412k$2tt9$3@digitaldaemon.com...
>
> "Walter" <newshound@digitalmars.com> wrote in message
news:cg40au$2thv$4@digitaldaemon.com...
> > 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.)
>
> I'm interested right now in whether reading that thread's made you more or
less interested in native threading support
> for D than you were the last time we discussed it?

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?

> (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 ???)

I don't see a problem there, platforms that don't support multithreading will just have noops for the sync primitives.

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. :)
>
>

[I'm cross posting to dtl group. Can you *only* answer in that group, and then we've move it over nicely. :)]

Done.

I like the look of it so far.

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.

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!)

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. :)
> >
> >
>
>

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

Hey Matthew I think std.loader is a nice piece of code and was complaining about it because I didn't know about -ldl.
Oh yes and having it be compiled into phobos on linux would be nice too.
*cheers*

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

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).

Walter wrote:
Added special 'length' inside array [ ]'s.

Yay!