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

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

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'

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

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.

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

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.

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

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

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.

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

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

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

considerable, albiet sugary, syntactic simplification.
Now, how do I go about raising the issue of D providing thread-agnostic

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

considerable, albiet sugary, syntactic simplification.
Now, how do I go about raising the issue of D providing thread-agnostic

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

No. Checking out ...
Sounds like Andrei's demanding for C++ what I've said to you several times

share the view with some of the respondents that it's not

Atomic ops, lock-free containers, etc. etc. We can do it. (But maybe this

I'm interested right now in whether reading that thread's made you more or

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

be a worthy pact, since this would be one area in which D would be

flowing ???)

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

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

considerable, albiet sugary, syntactic simplification.
Now, how do I go about raising the issue of D providing thread-agnostic

(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

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.

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.

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

Walter" <newshound digitalmars.com> wrote in message

2.0. BTW, are you following Andrei A's thread on adding lock-free

containers to C++? It's a great read in comp.lang.c++.moderated under

thread "Multithreaded programming: is the C++ standardization

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

[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

Walter" <newshound digitalmars.com> wrote in message

2.0. BTW, are you following Andrei A's thread on adding lock-free

containers to C++? It's a great read in comp.lang.c++.moderated under

thread "Multithreaded programming: is the C++ standardization

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

Question: what's the purpose of using "volatile" in various places. Since,

memory coherence, and do not cross-thread contention, aren't these

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.

Question: what's the purpose of using "volatile" in various places. Since,

memory coherence, and do not cross-thread contention, aren't these

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.

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

Question: what's the purpose of using "volatile" in various places. Since,

memory coherence, and do not cross-thread contention, aren't these

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.

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.

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

I don't think we're going to be able to keep it in the same format for

the container implementations as consistent as possible, in terms of

considerably.
Obviously there'll be deeper changes as well, such as templatisation, and

transformations/filters.

Sure ... edit with aplomb <g>

Question: what's the purpose of using "volatile" in various places. Since,

memory coherence, and do not cross-thread contention, aren't these

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

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

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

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.

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

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

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

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?

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

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:
# class Singleton
# {
# static Singleton s;
#
# Singleton instance()
# {
# volatile Singleton tmp = s;
# if(!tmp)
# {
# synchronized
# {
# tmp = s;
# if(!tmp)
# {
# volatile tmp = new Singleton();
# s = tmp;
# }
# }
# }
# return s;
# }
# }
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:
# volatile tmp = new Singleton();
with:
# volatile {
# tmp = new Singleton();
# // do stuff
# }
Sean

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

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

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

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

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

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

bit is something Walter could answer?
For the record, I *think* this is a correct implementation of the DCLP in

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

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

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

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

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

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

Mango). No compile errors ~ emits:
A
B
In fact, the only obvious means to get the output in a different order is

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

Am I being particularly dense today?

Static constructors are simply executed in the lexical order in which they
appear.

I don't think we're going to be able to keep it in the same format for

the container implementations as consistent as possible, in terms of

considerably.
Obviously there'll be deeper changes as well, such as templatisation, and

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,

memory coherence, and do not cross-thread contention, aren't these

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

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

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

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

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

Neat stuff Ben. Here's something that'll help if you haven't done this

(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

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

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!

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

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*

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

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

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