www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD 0.99 release

reply "Walter" <newshound digitalmars.com> writes:
Lots more bug fixes. Added special 'length' inside array [ ]'s.

http://www.digitalmars.com/d/changelog.html
Aug 19 2004
next sibling parent reply kinghajj <kinghajj_member pathlink.com> writes:
In article <cg3n60$2oap$1 digitaldaemon.com>, Walter says...

Added special 'length' inside array [ ]'s.


meaning ? ... (example please)
Aug 19 2004
next sibling parent "Carlos Santander B." <carlos8294 msn.com> writes:
"kinghajj" <kinghajj_member pathlink.com> escribió en el mensaje
news:cg3oju$2p20$1 digitaldaemon.com
| In article <cg3n60$2oap$1 digitaldaemon.com>, Walter says...
||
|| Added special 'length' inside array [ ]'s.
||
|
| meaning ? ... (example please)

Look for "Array Length" in arrays.html:

"Within the [ ] of a static or a dynamic array, the variable length is
implicitly declared and set to the length of the array."

-----------------------
Carlos Santander Bernal
Aug 19 2004
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 20 Aug 2004 02:45:18 +0000 (UTC), kinghajj wrote:


 In article <cg3n60$2oap$1 digitaldaemon.com>, Walter says...

Added special 'length' inside array [ ]'s.


 
 meaning ? ... (example please)


char[] myarray = "abcdefghij";

writef(myarray[length-3 .. length ]

output ==> "hij"

-- 
Derek
Melbourne, Australia
20/Aug/04 12:47:50 PM
Aug 19 2004
parent kinghajj <kinghajj_member pathlink.com> writes:
In article <cg3or0$2p3k$1 digitaldaemon.com>, Derek Parnell says...

On Fri, 20 Aug 2004 02:45:18 +0000 (UTC), kinghajj wrote:


 In article <cg3n60$2oap$1 digitaldaemon.com>, Walter says...

Added special 'length' inside array [ ]'s.


 
 meaning ? ... (example please)


char[] myarray = "abcdefghij";

writef(myarray[length-3 .. length ]

output ==> "hij"

-- 
Derek
Melbourne, Australia
20/Aug/04 12:47:50 PM


Oh, ok, that's cool!
Aug 19 2004
prev sibling next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Walter wrote:


 Lots more bug fixes. Added special 'length' inside array [ ]'s.
 
 http://www.digitalmars.com/d/changelog.html


I don't suppose there's any way to get that sugar for things that implement
opIndex, opSlice, etc. Or that that work already? I'm thinking that if x is
an instance of class Foo and Foo defined opIndex and length() then
x[length-1] is the same as x.opIndex(x.length-1).
Aug 19 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:cg3oug$2ond$1 digitaldaemon.com...

 Walter wrote:


 Lots more bug fixes. Added special 'length' inside array [ ]'s.

 http://www.digitalmars.com/d/changelog.html


 I don't suppose there's any way to get that sugar for things that


implement

 opIndex, opSlice, etc. Or that that work already? I'm thinking that if x


is

 an instance of class Foo and Foo defined opIndex and length() then
 x[length-1] is the same as x.opIndex(x.length-1).


That does need to be done. I was thinking that an implicit 'with' statement
could happen, and then all the members of the class instance would be
usable.
Aug 19 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cg3sh1$2qr1$1 digitaldaemon.com...

 "Ben Hinkle" <bhinkle4 juno.com> wrote in message
 news:cg3oug$2ond$1 digitaldaemon.com...

 Walter wrote:


 Lots more bug fixes. Added special 'length' inside array [ ]'s.

 http://www.digitalmars.com/d/changelog.html


 I don't suppose there's any way to get that sugar for things that


 implement

 opIndex, opSlice, etc. Or that that work already? I'm thinking that if x


 is

 an instance of class Foo and Foo defined opIndex and length() then
 x[length-1] is the same as x.opIndex(x.length-1).


 That does need to be done. I was thinking that an implicit 'with' statement
 could happen, and then all the members of the class instance would be
 usable.


Yikes no.

Please, in the words of the expository master: "do as the ints do" and the
relativistic master: "as simple as possible,
but no simpler".
Aug 19 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cg3v1i$2t3r$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message


news:cg3sh1$2qr1$1 digitaldaemon.com...

 "Ben Hinkle" <bhinkle4 juno.com> wrote in message
 news:cg3oug$2ond$1 digitaldaemon.com...

 Walter wrote:


 Lots more bug fixes. Added special 'length' inside array [ ]'s.

 http://www.digitalmars.com/d/changelog.html


 I don't suppose there's any way to get that sugar for things that


 implement

 opIndex, opSlice, etc. Or that that work already? I'm thinking that if






x

 is

 an instance of class Foo and Foo defined opIndex and length() then
 x[length-1] is the same as x.opIndex(x.length-1).


 That does need to be done. I was thinking that an implicit 'with'




statement

 could happen, and then all the members of the class instance would be
 usable.


 Yikes no.

 Please, in the words of the expository master: "do as the ints do" and the


relativistic master: "as simple as possible,

 but no simpler".


How else to supply the length? Just make that member visible?
Aug 19 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cg40as$2thv$1 digitaldaemon.com...

 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cg3v1i$2t3r$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message


 news:cg3sh1$2qr1$1 digitaldaemon.com...

 "Ben Hinkle" <bhinkle4 juno.com> wrote in message
 news:cg3oug$2ond$1 digitaldaemon.com...

 Walter wrote:


 Lots more bug fixes. Added special 'length' inside array [ ]'s.

 http://www.digitalmars.com/d/changelog.html


 I don't suppose there's any way to get that sugar for things that


 implement

 opIndex, opSlice, etc. Or that that work already? I'm thinking that if






 x

 is

 an instance of class Foo and Foo defined opIndex and length() then
 x[length-1] is the same as x.opIndex(x.length-1).


 That does need to be done. I was thinking that an implicit 'with'




 statement

 could happen, and then all the members of the class instance would be
 usable.


 Yikes no.

 Please, in the words of the expository master: "do as the ints do" and the


 relativistic master: "as simple as possible,

 but no simpler".


 How else to supply the length? Just make that member visible?


I like Chris' suggestion of opLength(), but if not I'd settle for the compiler
making length a special case.

Of course, if it's going to be a special case, then why not an operator.

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.
Aug 19 2004
parent reply Sean Kelly <sean f4.ca> writes:
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
Aug 20 2004
next sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:cg5e3f$iep$1 digitaldaemon.com...

 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.


Certainly, one the main points is to keep handling of all types consistent.

And, yes, I like the application the principle of sizeof() also.
Aug 20 2004
prev sibling parent "Thomas Kuehne" <eisvogel users.sourceforge.net> writes:
Sean Kelly schrieb in <cg5e3f$iep$1 digitaldaemon.com>:

 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.


I strongly opose this. This will break lots of existing length() etc.
functions.

If ever enable this only when a special pragma switch is included in the
sources.

Thomas
Aug 20 2004
prev sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Ben Hinkle" <bhinkle4 juno.com> wrote in message
news:cg3oug$2ond$1 digitaldaemon.com...

 Walter wrote:


 Lots more bug fixes. Added special 'length' inside array [ ]'s.

 http://www.digitalmars.com/d/changelog.html


 I don't suppose there's any way to get that sugar for things that implement
 opIndex, opSlice, etc. Or that that work already? I'm thinking that if x is
 an instance of class Foo and Foo defined opIndex and length() then
 x[length-1] is the same as x.opIndex(x.length-1).


I never considered that that was _not_ the case. Please say that is indeed how
it works, big-W.

If not, count this a loud vote for that consistency. :)
Aug 19 2004
parent "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cg3uu9$2t1b$1 digitaldaemon.com...

 "Ben Hinkle" <bhinkle4 juno.com> wrote in message


news:cg3oug$2ond$1 digitaldaemon.com...

 Walter wrote:


 Lots more bug fixes. Added special 'length' inside array [ ]'s.

 http://www.digitalmars.com/d/changelog.html


 I don't suppose there's any way to get that sugar for things that




implement

 opIndex, opSlice, etc. Or that that work already? I'm thinking that if x




is

 an instance of class Foo and Foo defined opIndex and length() then
 x[length-1] is the same as x.opIndex(x.length-1).


 I never considered that that was _not_ the case. Please say that is indeed


how it works, big-W.

 If not, count this a loud vote for that consistency. :)


Right now it only works for arrays.
Aug 19 2004
prev sibling next sibling parent reply "Vathix" <vathixSpamFix dprogramming.com> writes:
 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.
Aug 19 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"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
Aug 19 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cg3v1j$2t3r$2 digitaldaemon.com...

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


Most of the proposals involved things like using a special token like $, but
I thought we're already using length, so why not just continue that
direction?
Aug 19 2004
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cg40at$2thv$3 digitaldaemon.com...

 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cg3v1j$2t3r$2 digitaldaemon.com...

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


 Most of the proposals involved things like using a special token like $, but
 I thought we're already using length, so why not just continue that
 direction?


Oh sure, we agree on the syntax. Just that the special symbol for the length
operator should be, er, "length". :-)
Aug 19 2004
prev sibling parent Daniel Horn <hellcatv hotmail.com> writes:
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
Aug 20 2004
prev sibling next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
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!)
Aug 19 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"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?"
Aug 19 2004
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"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 ???)
Aug 19 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Aug 20 2004
parent Sean Kelly <sean f4.ca> writes:
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
Aug 20 2004
prev sibling parent Sean Kelly <sean f4.ca> writes:
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
Aug 20 2004
prev sibling next sibling parent reply "antiAlias" <fu bar.com> writes:
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.
Aug 19 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"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. :)
Aug 19 2004
parent reply "antiAlias" <fu bar.com> writes:
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. :)
Aug 20 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
[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. :)
Aug 20 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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

definitions of volatile to suit as well.
Aug 20 2004
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <cg59uu$gfi$1 digitaldaemon.com>, Walter says...

"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

definitions of volatile to suit as well.


Yup.  Andrei and Scott co-wrote articles in the July and August editions of DDJ
about this ("C++ and the Perils of Double-Checked Locking").  There was also a
thread about it in comp.std.c++.  It all boils down to the evil of the "as-if"
rule.


Sean
Aug 20 2004
prev sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cg59uu$gfi$1 digitaldaemon.com...

 "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

 definitions of volatile to suit as well.


Ok.

But I'll need you to fine-grain some examples for me before that coallesces
into a genuine understanding.

Maybe we can do this in written form somewhere soon? ;)
Aug 20 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cg5tjc$sdr$1 digitaldaemon.com...

 "Walter" <newshound digitalmars.com> wrote in message


news:cg59uu$gfi$1 digitaldaemon.com...

 "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






their

 definitions of volatile to suit as well.


 Ok.

 But I'll need you to fine-grain some examples for me before that


coallesces into a genuine understanding.

 Maybe we can do this in written form somewhere soon? ;)


See the July and August DDJ's by Andrei and Scott. They understand the
issues far better than I, and my brain hurts every time I try to figure it
out again.
Aug 21 2004
parent Sean Kelly <sean f4.ca> writes:
In article <cg7361$1mmk$1 digitaldaemon.com>, Walter says...

See the July and August DDJ's by Andrei and Scott. They understand the
issues far better than I, and my brain hurts every time I try to figure it
out again.


The discussions on threading in comp.std.c++ are getting pretty involved, so any
of those would be a good resource.  And lurking on comp.lang.threads is always
helpful, though it can take some searching to catch up on the lingo.  It seems
there's a pretty big movement towards lockless thread synchronization, and D is
already in a better position than most other languages to take advantage of
this.  I know that Ben was working on some lockless containers... I'll have to
find some time to check them out.


Sean
Aug 27 2004
prev sibling parent reply "antiAlias" <fu bar.com> writes:
"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. :)
Aug 20 2004
next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Aug 20 2004
parent reply Sean Kelly <sean f4.ca> writes:
In article <cg5jfh$lr9$1 digitaldaemon.com>, Walter says...

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


It might be nice to also offer a way to separate acquire/release semantics for
folks who care.  I can't think of a clean way to do this offhand, but perhaps:

volatile(acquire)
volatile(release)


Sean
Aug 20 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:cg5ran$qvc$1 digitaldaemon.com...

 In article <cg5jfh$lr9$1 digitaldaemon.com>, Walter says...

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


 It might be nice to also offer a way to separate acquire/release semantics for
 folks who care.  I can't think of a clean way to do this offhand, but perhaps:

 volatile(acquire)
 volatile(release)


Can we do block volatile, as in:

    volatile
    {
        ...
    }

Is that even meaningful?
Aug 20 2004
parent reply Sean Kelly <sean f4.ca> writes:
In article <cg5tje$sdr$3 digitaldaemon.com>, Matthew says...

"Sean Kelly" <sean f4.ca> wrote in message
news:cg5ran$qvc$1 digitaldaemon.com...

 In article <cg5jfh$lr9$1 digitaldaemon.com>, Walter says...

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


 It might be nice to also offer a way to separate acquire/release semantics for
 folks who care.  I can't think of a clean way to do this offhand, but perhaps:

 volatile(acquire)
 volatile(release)


Can we do block volatile, as in:

    volatile
    {
        ...
    }

Is that even meaningful?


volatile is a statement specifier, so yes.  Is it meaningful?  I think it could
be.  Memory barriers are far cheaper than locks but they aren't free.  I think a
volatile block would basically put an acquire barrier at the beginning of the
block and a release barrier at the end.  This would basically say that "this
block of code can not be reordered with respect to the surrounding code" though
I think the code *within* the block could still be reordered.  Perhaps this last
bit is something Walter could answer?

For the record, I *think* this is a correct implementation of the DCLP in D:
























With the above, the block volatile might be useful if we wanted to do extra
initialization of the singleton before assigning to s, thus replacing:



with:







Sean
Aug 20 2004
next sibling parent reply "antiAlias" <fu bar.com> writes:
You'll forgive me Sean, but the double-locking 'style' was driven out of
Java developers after it was shown to be mostly futile (I think it may have
been Doug Lea who demonstrated that). The recommended approach over there is
to construct singletons statically; which is where a 'static final'
assignment would be really useful in D:

static final Whatever singleton = new Whatever (...);

I know you've run into this need before. For those who don't know, the D
approach is thus:

static Whatever singleton;

static this()
{
    singleton = new Whatever (...);
}

Would be nice to have the former syntactic-sugar; but I imagine it would add
the same compiler complexity as static-constructors do, in terms of figuring
out the interdependencies across multiple related 'static final'
assignments.

Which leads to a question: how does the compiler deal with circular
dependencies across static-constructors? Let's try it out ...

class A
{
        static B b;

        static this()
        {
                printf ("A\n");
                b = new B;
        }
}

class B
{
        static A a;

        static this()
        {
                printf ("B\n");
                a = new A;
        }
}

Note that I wouldn't recommend this as a practice to anyone, but it may
occur accidentally where multiple modules are involved (I've done that with
Mango). No compile errors ~ emits:
A
B

In fact, the only obvious means to get the output in a different order is to
switch the class order within the file; that is, placing B above A yields:
B
A

Is there no dependency checking done for static constructors? Is this a bug?
Am I being particularly dense today?

n.b. the documentation for static constructors is apparently out-of-date.




"Sean Kelly" <sean f4.ca> wrote in message
news:cg5uva$t06$1 digitaldaemon.com...

 volatile is a statement specifier, so yes.  Is it meaningful?  I think it


could

 be.  Memory barriers are far cheaper than locks but they aren't free.  I


think a

 volatile block would basically put an acquire barrier at the beginning of


the

 block and a release barrier at the end.  This would basically say that


"this

 block of code can not be reordered with respect to the surrounding code"


though

 I think the code *within* the block could still be reordered.  Perhaps


this last

 bit is something Walter could answer?

 For the record, I *think* this is a correct implementation of the DCLP in


D:
























 With the above, the block volatile might be useful if we wanted to do


extra

 initialization of the singleton before assigning to s, thus replacing:



 with:







 Sean
Aug 20 2004
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <cg61nf$u96$1 digitaldaemon.com>, antiAlias says...

You'll forgive me Sean, but the double-locking 'style' was driven out of
Java developers after it was shown to be mostly futile (I think it may have
been Doug Lea who demonstrated that).


That's fine :)  I mostly used it as an example beceause I had the Andrei and
Scott's DDJ articles on it in front of me at the time.


The recommended approach over there is to construct singletons statically


Yup.  And this would work in D just as well.  Since apps all begin with only one
thread, eager construction seems to make far more sense than the lazy method.


Which leads to a question: how does the compiler deal with circular
dependencies across static-constructors? Let's try it out ...

class A
{
        static B b;

        static this()
        {
                printf ("A\n");
                b = new B;
        }
}

class B
{
        static A a;

        static this()
        {
                printf ("B\n");
                a = new A;
        }
}

Note that I wouldn't recommend this as a practice to anyone, but it may
occur accidentally where multiple modules are involved (I've done that with
Mango). No compile errors ~ emits:
A
B

In fact, the only obvious means to get the output in a different order is to
switch the class order within the file; that is, placing B above A yields:
B
A

Is there no dependency checking done for static constructors? Is this a bug?
Am I being particularly dense today?


I was wondering about this.  What if A and B were in separate modules?


Sean
Aug 20 2004
parent "Walter" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:cg62jg$umv$1 digitaldaemon.com...

 I was wondering about this.  What if A and B were in separate modules?


You'll get an error about circular dependencies.
Aug 22 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"antiAlias" <fu bar.com> wrote in message
news:cg61nf$u96$1 digitaldaemon.com...

 You'll forgive me Sean, but the double-locking 'style' was driven out of
 Java developers after it was shown to be mostly futile (I think it may


have

 been Doug Lea who demonstrated that). The recommended approach over there


is

 to construct singletons statically; which is where a 'static final'
 assignment would be really useful in D:

 static final Whatever singleton = new Whatever (...);

 I know you've run into this need before. For those who don't know, the D
 approach is thus:

 static Whatever singleton;

 static this()
 {
     singleton = new Whatever (...);
 }

 Would be nice to have the former syntactic-sugar; but I imagine it would


add

 the same compiler complexity as static-constructors do, in terms of


figuring

 out the interdependencies across multiple related 'static final'
 assignments.

 Which leads to a question: how does the compiler deal with circular
 dependencies across static-constructors? Let's try it out ...

 class A
 {
         static B b;

         static this()
         {
                 printf ("A\n");
                 b = new B;
         }
 }

 class B
 {
         static A a;

         static this()
         {
                 printf ("B\n");
                 a = new A;
         }
 }

 Note that I wouldn't recommend this as a practice to anyone, but it may
 occur accidentally where multiple modules are involved (I've done that


with

 Mango). No compile errors ~ emits:
 A
 B

 In fact, the only obvious means to get the output in a different order is


to

 switch the class order within the file; that is, placing B above A yields:
 B
 A

 Is there no dependency checking done for static constructors? Is this a


bug?

 Am I being particularly dense today?


Static constructors are simply executed in the lexical order in which they
appear.
Aug 22 2004
prev sibling parent reply Gold Dragon <dragonwing dragonu.net> writes:




 
 
 Sean
 
 


What type is tmp? Wouldn't you get a compiler error if you don't put the 
  type or will the compiler automatically know like with um, well I 
can't think of an example.
Aug 20 2004
parent reply Sean Kelly <sean f4.ca> writes:
In article <cg6bs8$1325$1 digitaldaemon.com>, Gold Dragon says...





 
 
 Sean
 
 


What type is tmp? Wouldn't you get a compiler error if you don't put the 
  type or will the compiler automatically know like with um, well I 
can't think of an example.


Its type is Singleton.  tmp was delcared in the first line of the function as:

volatile tmp = s;


Sean
Aug 20 2004
parent Sean Kelly <sean f4.ca> writes:
Sean Kelly wrote:

 In article <cg6bs8$1325$1 digitaldaemon.com>, Gold Dragon says...
 







Sean


What type is tmp? Wouldn't you get a compiler error if you don't put the 
 type or will the compiler automatically know like with um, well I 
can't think of an example.


 
 
 Its type is Singleton.  tmp was delcared in the first line of the function as:
 
 volatile tmp = s;


err... I meant:

volatile Singleton tmp = s;


Sean
Aug 21 2004
prev sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"antiAlias" <fu bar.com> wrote in message news:cg5i6n$l3k$1 digitaldaemon.com...

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


Thanks, though I suspect it'll be more rotten plum than aplomb, but I'll do my
best.


 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. :)
Aug 20 2004
prev sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
 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...
Aug 20 2004
parent reply pragma <EricAnderton at yahoo dot com> <pragma_member pathlink.com> writes:
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
Aug 20 2004
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"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!
Aug 20 2004
prev sibling next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
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?
Aug 19 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"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
Aug 19 2004
next sibling parent clayasaurus <clayasaurus gmail.com> writes:
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*
Aug 20 2004
prev sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
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).
Aug 20 2004
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"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. :-)
Aug 20 2004
prev sibling next sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Walter wrote:
Added special 'length' inside array [ ]'s.

Yay!
Aug 20 2004
prev sibling parent David L. Davis <SpottedTiger yahoo.com> writes:
In article <cg3n60$2oap$1 digitaldaemon.com>, Walter says...

Lots more bug fixes. Added special 'length' inside array [ ]'s.

http://www.digitalmars.com/d/changelog.html


Walter: Thxs a lot for adding in the ifind() and irfind() functions into the
std.string...I'll be putting them to good use! :)) 

Also, will you be adding in the ireplace() and icount() as well? I wrote them up
and put them in a link just below ifind() functions back in mid-june, I'm not
sure if you want me to resubmit them or not. 

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
Aug 20 2004