www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Sharing in D

reply Walter Bright <newshound1 digitalmars.com> writes:
http://www.reddit.com/comments/6u7k0/sharing_in_d/
Jul 30 2008
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Walter Bright Wrote:

 http://www.reddit.com/comments/6u7k0/sharing_in_d/

WANT. It would be very useful for certain applications. However, I'm worried that this may perhaps add even more complexity to an already stretched type system. How about making the less safe alternative (shared/unchecked) the default (so current programs keep working the way they already do) and people who want the additional compelxity and overhead use unshared explicitly (just as const/invariant is not the default and people need to explicitly say that).
Jul 30 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Bartosz Milewski:
 This requires that all objects, by default, be thread local. For instance, if
you declare a global object and initialize it in one thread, another thread
will see a different version of this object.<

This requires to be careful using global variables, because you may need lot of memory. On the other hand, each L1 cache can keep such objects safely, with little need of copying such data to other L1 caches. Robert Fraser:
 However, I'm worried that this may perhaps add even more complexity
 to an already stretched type system.

If the type system is able to manage the transitive immutability, then it can manage this too, I think. The things that are going to stress the type system of D are different ones, I think; for example see the thread about nested templates, where the best solution proposed was to use an union to punch a hole in it. Bye, bearophile
Jul 31 2008
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
bearophile Wrote:
 Robert Fraser:
 However, I'm worried that this may perhaps add even more complexity
 to an already stretched type system.

If the type system is able to manage the transitive immutability, then it can manage this too, I think. The things that are going to stress the type system of D are different ones, I think; for example see the thread about nested templates, where the best solution proposed was to use an union to punch a hole in it.

I was talking UX wise. I don't want to have to think whether my variable is a shared(atomic(const(int)*)[]).
Jul 31 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 If the type system is able to manage the transitive immutability,
 then it can manage this too, I think.

I've already worked out the implementation issues of transitivity, so I can easily leverage that code for the sharing transitivity.
Jul 31 2008
prev sibling next sibling parent JAnderson <ask me.com> writes:
Walter Bright wrote:
 http://www.reddit.com/comments/6u7k0/sharing_in_d/

I like this proposal. Maybe the shared option could be in the typical bracket notation that D is so fond off: shared { Object X; //Shared object class Foo() {} //Shared class for any object that uses this / Shared members class Bar() {} } That way the few people that are passing non-shared objects around can simply put everything into a shared block, simplifying migration. -Joel
Jul 30 2008
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Walter Bright" wrote
 http://www.reddit.com/comments/6u7k0/sharing_in_d/

There are 2 problems I see with this scheme. First, that the default is 'unshared'. This is going to break a lot of existing code, and make peoples lives miserable who do not want to deal with unshared non-stack data. I would hazard to guess that adopting this would cause a larger rift than const. Second, the fact that you can't implicitly cast shared to unshared and vice versa. It's going to make communication between both 'worlds' very error prone, as you will be required to cast for any call from one to the other. People will do this just to get their code to work, without thinking about the consequences. Even those that do think about the consequences, can't have the compiler statically check the cast in either direction, so once you cast, you lose all the benefit. I'd have to see solutions to these before I'd think it was a good idea. Or else examples of how to avoid these problems. -Steve
Jul 30 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:
 "Walter Bright" wrote
 http://www.reddit.com/comments/6u7k0/sharing_in_d/

There are 2 problems I see with this scheme. First, that the default is 'unshared'. This is going to break a lot of existing code, and make peoples lives miserable who do not want to deal with unshared non-stack data.

Nearly all global data is assumed to be and treated as if it were unshared. So making unshared the default is the right solution. And frankly, if you're using a lot of global variables, you might want to reevaluate what you're doing. Lots of global variables is the 80's style of programming :-)
 I would hazard to guess that adopting this would 
 cause a larger rift than const.

Perhaps. But the alternative is the current wild west approach to multithreaded programming. With the proliferation of multicore computers, the era where this is acceptable is coming to an end.
 Second, the fact that you can't implicitly cast shared to unshared and vice 
 versa.  It's going to make communication between both 'worlds' very error 
 prone, as you will be required to cast for any call from one to the other.

I think the reverse is true. Moving data between those worlds is dangerous and needs to be carefully vetted, so requiring an explicit cast will reduce the chance of this happening unintentionally.
 People will do this just to get their code to work, without thinking about 
 the consequences.

True, but having it happen implicitly is even worse, because there's no indication that it is happening.
 Even those that do think about the consequences, can't 
 have the compiler statically check the cast in either direction, so once you 
 cast, you lose all the benefit.

But still, you're far better off than the current wild west approach where everything is implicitly shared with no protection whatsoever. The popular double checked locking bug will be impossible to code in D without stuffing in explicit casts. The casts will be a red flag that the programmer is making a mistake.
 I'd have to see solutions to these before I'd think it was a good idea.  Or 
 else examples of how to avoid these problems.

Jul 30 2008
next sibling parent reply downs <default_357-line yahoo.de> writes:
Walter Bright wrote:
 Steven Schveighoffer wrote:
 I would hazard to guess that adopting this would cause a larger rift
 than const.


He's probably right.
 
 Perhaps. But the alternative is the current wild west approach to
 multithreaded programming. With the proliferation of multicore
 computers, the era where this is acceptable is coming to an end.
 

Since when is it the language's job to tell us what's acceptable and what's not?
 But still, you're far better off than the current wild west approach
 where everything is implicitly shared with no protection whatsoever. The
 popular double checked locking bug will be impossible to code in D
 without stuffing in explicit casts. The casts will be a red flag that
 the programmer is making a mistake.
 

The double checked locking "bug" is only a bug on certain architectures, none of which D is supported on. What's the point here again? --downs
Jul 31 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
downs wrote:
 Walter Bright wrote:
 Steven Schveighoffer wrote:
 I would hazard to guess that adopting this would cause a larger
 rift than const.



A couple years ago, I was in a room with 30 of the top C++ programmers in the country. The topic was a 2 day conference on how to support multithreading in C++. It soon became clear that only two people in the room understood the issues (and I wasn't one of them). I think I understand the issues now, but it has taken a long time and repeatedly reading the papers about it. It is not simple, and it's about as intuitive as quantum mechanics. I suggested to Andrei and Bartosz just the other day that I don't expect the value in this model will be readily apparent. I'm pretty sure it won't be, as the issues are hard to understand. But the issues being hard to understand is exactly why this model is needed. There are surely several articles, papers, and tutorials in this :-)
 Perhaps. But the alternative is the current wild west approach to 
 multithreaded programming. With the proliferation of multicore 
 computers, the era where this is acceptable is coming to an end.

Since when is it the language's job to tell us what's acceptable and what's not?

I meant that programmers will no longer find the language acceptable if it doesn't offer better support.
 But still, you're far better off than the current wild west
 approach where everything is implicitly shared with no protection
 whatsoever. The popular double checked locking bug will be
 impossible to code in D without stuffing in explicit casts. The
 casts will be a red flag that the programmer is making a mistake.

The double checked locking "bug" is only a bug on certain architectures, none of which D is supported on.

D is not only meant to be more than an x86 only language, the x86 family steadily moves towards the relaxed sequential consistency model. The threading model supported by Java and the upcoming C++0x release are both based on the relaxed model, that is clearly where the industry expects things to go, and I see no reason to believe otherwise.
Jul 31 2008
next sibling parent reply downs <default_357-line yahoo.de> writes:
Walter Bright wrote:
 downs wrote:
 Walter Bright wrote:
 Steven Schveighoffer wrote:
 I would hazard to guess that adopting this would cause a larger
 rift than const.



A couple years ago, I was in a room with 30 of the top C++ programmers in the country. The topic was a 2 day conference on how to support multithreading in C++. It soon became clear that only two people in the room understood the issues (and I wasn't one of them). I think I understand the issues now, but it has taken a long time and repeatedly reading the papers about it. It is not simple, and it's about as intuitive as quantum mechanics. I suggested to Andrei and Bartosz just the other day that I don't expect the value in this model will be readily apparent. I'm pretty sure it won't be, as the issues are hard to understand. But the issues being hard to understand is exactly why this model is needed. There are surely several articles, papers, and tutorials in this :-)
 Perhaps. But the alternative is the current wild west approach to
 multithreaded programming. With the proliferation of multicore
 computers, the era where this is acceptable is coming to an end.

Since when is it the language's job to tell us what's acceptable and what's not?

I meant that programmers will no longer find the language acceptable if it doesn't offer better support.
 But still, you're far better off than the current wild west
 approach where everything is implicitly shared with no protection
 whatsoever. The popular double checked locking bug will be
 impossible to code in D without stuffing in explicit casts. The
 casts will be a red flag that the programmer is making a mistake.

The double checked locking "bug" is only a bug on certain architectures, none of which D is supported on.

D is not only meant to be more than an x86 only language, the x86 family steadily moves towards the relaxed sequential consistency model. The threading model supported by Java and the upcoming C++0x release are both based on the relaxed model, that is clearly where the industry expects things to go, and I see no reason to believe otherwise.

Point taken, taken and taken. If this can be done well, I believe it may become a significant advantage for the language. IMHO, however, most global variables are intended to be instantiated only once, not once per thread. Because of this, the success of this model hinges on how easy an object can be transferred between threads. Some sort of language enforced blocking, maybe? I.e. if you mark an object as unique, as in, "unique Class foo", it is implicitly shared, but *treated as if it were nonshared*, as threads need to acquire a sync lock before accessing the object, and references to the object or its members cannot leave the sync block. Delegates would be a special case: they can leave the sync lock, as long as any "this" access inside them is itself synchronized. --downs
Jul 31 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
downs wrote:
 IMHO, however, most global variables are intended to be instantiated
 only once, not once per thread. Because of this, the success of this
 model hinges on how easy an object can be transferred between
 threads. Some sort of language enforced blocking, maybe?

The idea is to no longer allow unsynchronized uncontrolled sharing of data between threads as the *default* behavior. If you want to do it, you'll have to do it *intentionally*. Note that invariant data will be implicitly shared because it does not need synchronization or fencing.
Jul 31 2008
parent reply downs <default_357-line yahoo.de> writes:
Walter Bright wrote:
 downs wrote:
 IMHO, however, most global variables are intended to be instantiated
 only once, not once per thread. Because of this, the success of this
 model hinges on how easy an object can be transferred between
 threads. Some sort of language enforced blocking, maybe?

The idea is to no longer allow unsynchronized uncontrolled sharing of data between threads as the *default* behavior. If you want to do it, you'll have to do it *intentionally*.

Yeah, but I'd like a way to do it that doesn't leave me entirely on my own, considering that it's imho a common use-case.
Jul 31 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
downs wrote:
 Walter Bright wrote:
 downs wrote:
 IMHO, however, most global variables are intended to be
 instantiated only once, not once per thread. Because of this, the
 success of this model hinges on how easy an object can be
 transferred between threads. Some sort of language enforced
 blocking, maybe?

of data between threads as the *default* behavior. If you want to do it, you'll have to do it *intentionally*.

Yeah, but I'd like a way to do it that doesn't leave me entirely on my own, considering that it's imho a common use-case.

I don't understand what you're asking for.
Jul 31 2008
parent reply downs <default_357-line yahoo.de> writes:
Walter Bright wrote:
 downs wrote:
 Walter Bright wrote:
 downs wrote:
 IMHO, however, most global variables are intended to be
 instantiated only once, not once per thread. Because of this, the
 success of this model hinges on how easy an object can be
 transferred between threads. Some sort of language enforced
 blocking, maybe?

of data between threads as the *default* behavior. If you want to do it, you'll have to do it *intentionally*.

Yeah, but I'd like a way to do it that doesn't leave me entirely on my own, considering that it's imho a common use-case.

I don't understand what you're asking for.

Sorry. I am looking for a safe way to transfer ownership of a single object between threads. Like, for instance, a "unique Object foo" would behave like a shared Object, but the compiler would treat it like a nonshared object for purposes of optimization, and all accesses from the outside would be implicitly synchronized. This could be used for objects that really are only supposed to exist once, but still used in a multithreaded way. Hope that clears things up.
Aug 01 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
downs wrote:
 I am looking for a safe way to transfer ownership of a single object
 between threads.
 
 Like, for instance, a "unique Object foo" would behave like a shared
 Object, but the compiler would treat it like a nonshared object for
 purposes of optimization, and all accesses from the outside would be
 implicitly synchronized.
 
 This could be used for objects that really are only supposed to exist
 once, but still used in a multithreaded way.
 
 Hope that clears things up.

Sorry, I still have no idea what you're asking for.
Aug 01 2008
parent reply downs <default_357-line yahoo.de> writes:
Walter Bright wrote:
 downs wrote:
 I am looking for a safe way to transfer ownership of a single object
 between threads.

 Like, for instance, a "unique Object foo" would behave like a shared
 Object, but the compiler would treat it like a nonshared object for
 purposes of optimization, and all accesses from the outside would be
 implicitly synchronized.

 This could be used for objects that really are only supposed to exist
 once, but still used in a multithreaded way.

 Hope that clears things up.

Sorry, I still have no idea what you're asking for.

Okay. In the current system, every object "belongs" to every thread equally - synchronization blocks are used to prevent interference. In the new system, this behavior, if I understand correctly, is equivalent to "shared". The default, non-shared, would be objects that belong, permanently, to exactly one thread - the one that created them, to the extent that accessing them from another thread would constitute a compiler failure. What I am looking for, then, is to somehow temporarily, or permanently, change the thread that a specific instance belongs to, transfer ownership to another thread, so to speak, in an atomic manner - so that at no time more than one thread possesses ownership of the object - thus gaining, basically, the guaranteed thread-safety of a non-shared object with the convenience of a shared object. So it's basically a form of forced "synchronized" blocks - a thread that would try to access such an "unique" object, would first have to acquire ownership of it, to prevent threading issues - an action similar to the current "synchronized(this)". In fact, every access to an unique object would come down to an implicit "synchronized(obj)", which would allow us to treat the object as if it _were_ thread-local for the purpose of that access, because even though it isn't, no other thread could interfere with it. Hope that clears things up :/
Aug 01 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from downs (default_357-line yahoo.de)'s article
 Walter Bright wrote:
 downs wrote:
 I am looking for a safe way to transfer ownership of a single object
 between threads.

 Like, for instance, a "unique Object foo" would behave like a shared
 Object, but the compiler would treat it like a nonshared object for
 purposes of optimization, and all accesses from the outside would be
 implicitly synchronized.

 This could be used for objects that really are only supposed to exist
 once, but still used in a multithreaded way.

 Hope that clears things up.

Sorry, I still have no idea what you're asking for.

In the current system, every object "belongs" to every thread equally -

 In the new system, this behavior, if I understand correctly, is equivalent to

 The default, non-shared, would be objects that belong, permanently, to exactly

another thread would constitute a compiler failure.
 What I am looking for, then, is to somehow temporarily, or permanently, change

thread, so to speak, in an atomic manner - so that at no time more than one thread possesses ownership of the object - thus gaining, basically, the guaranteed thread-safety of a non-shared object with the convenience of a shared object. We've discussed creating per-thread GCs in Tango to eliminate the problem of "stop the world" collections. Transferral of ownership is complicated with such a model, however, if the object being transferred represents a resource. Everything else you can just .dup (ie. perform a deep copy), but obviously not singletons. I'd be inclined to say that this is a limitation you'll just have to deal with when designing your program. Make one thread the "owner" of the object and have other threads interact with it basically via messaging. This idea of per-thread GCs dovetails perfectly with 'shared' as well, since there's no way in D 1.0 to flag the creation of static data. In D 2.0 however, it sounds like all such data either must be labeled 'shared' or can be made thread-local as well. Totally awesome. Of course, that still means that memory backing shared data will leak in the absence of a GC, so either this would have to be stated and the user would have to deal with it, or there would still need to be a global "stop the world" GC specifically for the shared data. In the latter case, I'd probably default the GC to disabled so the user would either collect manually or enable it if he doesn't care about an occasional "stop the world" collection. Sean
Aug 01 2008
next sibling parent JAnderson <ask me.com> writes:
Sean Kelly wrote:
 == Quote from downs (default_357-line yahoo.de)'s article
 Walter Bright wrote:
 downs wrote:
 I am looking for a safe way to transfer ownership of a single object
 between threads.

 Like, for instance, a "unique Object foo" would behave like a shared
 Object, but the compiler would treat it like a nonshared object for
 purposes of optimization, and all accesses from the outside would be
 implicitly synchronized.

 This could be used for objects that really are only supposed to exist
 once, but still used in a multithreaded way.

 Hope that clears things up.


In the current system, every object "belongs" to every thread equally -

 In the new system, this behavior, if I understand correctly, is equivalent to

 The default, non-shared, would be objects that belong, permanently, to exactly

another thread would constitute a compiler failure.
 What I am looking for, then, is to somehow temporarily, or permanently, change

thread, so to speak, in an atomic manner - so that at no time more than one thread possesses ownership of the object - thus gaining, basically, the guaranteed thread-safety of a non-shared object with the convenience of a shared object. We've discussed creating per-thread GCs in Tango to eliminate the problem of "stop the world" collections. Transferral of ownership is complicated with such a model, however, if the object being transferred represents a resource. Everything else you can just .dup (ie. perform a deep copy), but obviously not singletons. I'd be inclined to say that this is a limitation you'll just have to deal with when designing your program. Make one thread the "owner" of the object and have other threads interact with it basically via messaging. This idea of per-thread GCs dovetails perfectly with 'shared' as well, since there's no way in D 1.0 to flag the creation of static data. In D 2.0 however, it sounds like all such data either must be labeled 'shared' or can be made thread-local as well. Totally awesome. Of course, that still means that memory backing shared data will leak in the absence of a GC, so either this would have to be stated and the user would have to deal with it, or there would still need to be a global "stop the world" GC specifically for the shared data. In the latter case, I'd probably default the GC to disabled so the user would either collect manually or enable it if he doesn't care about an occasional "stop the world" collection. Sean

Some good points. One thing that will likely happen with shared GC is that there will be relativity a very small amount of shared memory needed. Therefore GC collection on the shared memory might be fast enough for many people. If there's a lot of memory being shared its a sign that something might be wrong. That's because a huge amount of shared memory means that the benefit of multi-threading will seriously be diminished. Also maybe "shared" could eventually use a different kinda GC which is more optimal for shared memory. If there was a way to say which threads had read/write (or both) access to different shared memories then not all threads would need to be stopped. -Joel
Aug 02 2008
prev sibling parent reply Don <nospam nospam.com.au> writes:
Sean Kelly wrote:
 == Quote from downs (default_357-line yahoo.de)'s article
 Walter Bright wrote:
 downs wrote:
 I am looking for a safe way to transfer ownership of a single object
 between threads.

 Like, for instance, a "unique Object foo" would behave like a shared
 Object, but the compiler would treat it like a nonshared object for
 purposes of optimization, and all accesses from the outside would be
 implicitly synchronized.

 This could be used for objects that really are only supposed to exist
 once, but still used in a multithreaded way.

 Hope that clears things up.


In the current system, every object "belongs" to every thread equally -

 In the new system, this behavior, if I understand correctly, is equivalent to

 The default, non-shared, would be objects that belong, permanently, to exactly

another thread would constitute a compiler failure.
 What I am looking for, then, is to somehow temporarily, or permanently, change

thread, so to speak, in an atomic manner - so that at no time more than one thread possesses ownership of the object - thus gaining, basically, the guaranteed thread-safety of a non-shared object with the convenience of a shared object. We've discussed creating per-thread GCs in Tango to eliminate the problem of "stop the world" collections. Transferral of ownership is complicated with such a model, however, if the object being transferred represents a resource. Everything else you can just .dup (ie. perform a deep copy), but obviously not singletons. I'd be inclined to say that this is a limitation you'll just have to deal with when designing your program. Make one thread the "owner" of the object and have other threads interact with it basically via messaging. This idea of per-thread GCs dovetails perfectly with 'shared' as well, since there's no way in D 1.0 to flag the creation of static data. In D 2.0 however, it sounds like all such data either must be labeled 'shared' or can be made thread-local as well.

Would this be an end to 'static' variables?
Aug 14 2008
parent Sean Kelly <sean invisibleduck.org> writes:
Don wrote:
 Sean Kelly wrote:
 == Quote from downs (default_357-line yahoo.de)'s article
 Walter Bright wrote:
 downs wrote:
 I am looking for a safe way to transfer ownership of a single object
 between threads.

 Like, for instance, a "unique Object foo" would behave like a shared
 Object, but the compiler would treat it like a nonshared object for
 purposes of optimization, and all accesses from the outside would be
 implicitly synchronized.

 This could be used for objects that really are only supposed to exist
 once, but still used in a multithreaded way.

 Hope that clears things up.


In the current system, every object "belongs" to every thread equally -

 In the new system, this behavior, if I understand correctly, is 
 equivalent to

 The default, non-shared, would be objects that belong, permanently, 
 to exactly

them from another thread would constitute a compiler failure.
 What I am looking for, then, is to somehow temporarily, or 
 permanently, change

another thread, so to speak, in an atomic manner - so that at no time more than one thread possesses ownership of the object - thus gaining, basically, the guaranteed thread-safety of a non-shared object with the convenience of a shared object. We've discussed creating per-thread GCs in Tango to eliminate the problem of "stop the world" collections. Transferral of ownership is complicated with such a model, however, if the object being transferred represents a resource. Everything else you can just .dup (ie. perform a deep copy), but obviously not singletons. I'd be inclined to say that this is a limitation you'll just have to deal with when designing your program. Make one thread the "owner" of the object and have other threads interact with it basically via messaging. This idea of per-thread GCs dovetails perfectly with 'shared' as well, since there's no way in D 1.0 to flag the creation of static data. In D 2.0 however, it sounds like all such data either must be labeled 'shared' or can be made thread-local as well.

Would this be an end to 'static' variables?

I think that's the only feasible option for D1, which is why I'm hesitant to pursue per-thread GCs. It's a restriction that would have no language support but rather rely on convention to prevent crashes. For D2 I think it may be possible to rely on the transitivity of 'shared' and to use this type qualifier to allocate from a central "stop the world" GC. The tricky thing here is that local data would have to be copied if it were to be referenced only from the shared area, similar to an .idup I suppose. Sean
Aug 14 2008
prev sibling next sibling parent reply Helmut Leitner <leitner wikiservice.at> writes:
Walter Bright wrote:
 downs wrote:
 
 Walter Bright wrote:

 Steven Schveighoffer wrote:

 I would hazard to guess that adopting this would cause a larger
 rift than const.


He's probably right.

A couple years ago, I was in a room with 30 of the top C++ programmers in the country. The topic was a 2 day conference on how to support multithreading in C++. It soon became clear that only two people in the room understood the issues (and I wasn't one of them). I think I understand the issues now, but it has taken a long time and repeatedly reading the papers about it. It is not simple, and it's about as intuitive as quantum mechanics. I suggested to Andrei and Bartosz just the other day that I don't expect the value in this model will be readily apparent. I'm pretty sure it won't be, as the issues are hard to understand. But the issues being hard to understand is exactly why this model is needed. There are surely several articles, papers, and tutorials in this :-)

Perhaps this has already been discussed, but there seems another upcoming arms race between probably - NVIDIA/CUDA, currently available 200+ cores available at $500 - Intel multicore, probably available in 12+ months competing in - scientific number-crunching - life video encoding (hot topic) I think it would be a BIG marketing effect for D, if it could support the NVIDIA/CUDA system. Probably it would even get payed by NVIDIA. Helmut
Jul 31 2008
next sibling parent reply Helmut Leitner <leitner wikiservice.at> writes:
Koroskin Denis wrote:
 As a result, we could use a PS3 as a basis for an upcoming cuncurrent  
 programming support in D.
 I just don't see any other *real* possibilities to get 4 or more cores 
 for  a low price.

All NVIDIA graphics boards from 8400 up are usable via the CUDA interface. The newest GT200 chip that is build into the GTX-280 boards (GTX-260 has a just a lower core count) contains 240 cores. There is a number-crunching-only version of these graphics boards, called TESLA. The hi-end-boards promise to reach 1 TFLOP (single precision) and about 0.1 TFLOP (double precision). This is existing technology that is in the market.
Jul 31 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Helmut Leitner:
 This is existing technology that is in the market.

And it's working fast as hell already, I have tried CUDA some on my GPU :-) There's an impressive demo named Particles: http://www.youtube.com/watch?v=U5eJ8RdR68I http://www.youtube.com/watch?v=RqduA7myZok It works like this on a card that costs about 70-80 euro, and it's amazing. Bye, bearophile
Jul 31 2008
prev sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Helmut Leitner wrote:
 Walter Bright wrote:
 downs wrote:

 Walter Bright wrote:

 Steven Schveighoffer wrote:

 I would hazard to guess that adopting this would cause a larger
 rift than const.


He's probably right.

A couple years ago, I was in a room with 30 of the top C++ programmers in the country. The topic was a 2 day conference on how to support multithreading in C++. It soon became clear that only two people in the room understood the issues (and I wasn't one of them). I think I understand the issues now, but it has taken a long time and repeatedly reading the papers about it. It is not simple, and it's about as intuitive as quantum mechanics. I suggested to Andrei and Bartosz just the other day that I don't expect the value in this model will be readily apparent. I'm pretty sure it won't be, as the issues are hard to understand. But the issues being hard to understand is exactly why this model is needed. There are surely several articles, papers, and tutorials in this :-)

Perhaps this has already been discussed, but there seems another upcoming arms race between probably - NVIDIA/CUDA, currently available 200+ cores available at $500 - Intel multicore, probably available in 12+ months competing in - scientific number-crunching - life video encoding (hot topic) I think it would be a BIG marketing effect for D, if it could support the NVIDIA/CUDA system. Probably it would even get payed by NVIDIA. Helmut

This is a library realm topic, given the ability to mixin optimal code per the BLADE-esque technique.
Jul 31 2008
parent Kyle Furlong <kylefurlong gmail.com> writes:
Kyle Furlong wrote:
 Helmut Leitner wrote:
 Walter Bright wrote:
 downs wrote:

 Walter Bright wrote:

 Steven Schveighoffer wrote:

 I would hazard to guess that adopting this would cause a larger
 rift than const.


He's probably right.

A couple years ago, I was in a room with 30 of the top C++ programmers in the country. The topic was a 2 day conference on how to support multithreading in C++. It soon became clear that only two people in the room understood the issues (and I wasn't one of them). I think I understand the issues now, but it has taken a long time and repeatedly reading the papers about it. It is not simple, and it's about as intuitive as quantum mechanics. I suggested to Andrei and Bartosz just the other day that I don't expect the value in this model will be readily apparent. I'm pretty sure it won't be, as the issues are hard to understand. But the issues being hard to understand is exactly why this model is needed. There are surely several articles, papers, and tutorials in this :-)

Perhaps this has already been discussed, but there seems another upcoming arms race between probably - NVIDIA/CUDA, currently available 200+ cores available at $500 - Intel multicore, probably available in 12+ months competing in - scientific number-crunching - life video encoding (hot topic) I think it would be a BIG marketing effect for D, if it could support the NVIDIA/CUDA system. Probably it would even get payed by NVIDIA. Helmut

This is a library realm topic, given the ability to mixin optimal code per the BLADE-esque technique.

I spoke too soon, this would require asm support for those processors.
Jul 31 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 downs wrote:
 Walter Bright wrote:
 Steven Schveighoffer wrote:
 I would hazard to guess that adopting this would cause a larger
 rift than const.



in the country. The topic was a 2 day conference on how to support multithreading in C++. It soon became clear that only two people in the room understood the issues (and I wasn't one of them). I think I understand the issues now, but it has taken a long time and repeatedly reading the papers about it. It is not simple, and it's about as intuitive as quantum mechanics.

In my opinion, the easiest way to describe the hardware side of things is simply to say that the CPU does the exact same thing as the optimizer in the compiler, only it does this dynamically as the code is executing. The rest just involves ideas for how to constrain CPU and compiler optimizations so the app behaves as expected when concurrency is involved. In your defense, "volatile" is a perfectly suitable minimum for D, so you did get the gist of the issue, even at the outset. The catch is that, while "volatile" controls the compiler, you still need to control the CPU, so inline ASM is required as well. Fortunately, D has that :-) So please give yourself a bit more credit here. D1 works perfectly well for concurrent programming. It just support this is a sufficiently non-obvious way that only people who understand the issues involved are likely to realize it. But as most of this stuff should really be in a library anyway, I don't see a problem with things as they are. Finding a way for the average user to do safe concurrent programming is an entirely different issue in my opinion, and has only really been "solved," in my opinion, in the functional programming realm. And that's by eliminating data sharing--the bane of imperative languages everywhere.
 Perhaps. But the alternative is the current wild west approach to
 multithreaded programming. With the proliferation of multicore
 computers, the era where this is acceptable is coming to an end.

Since when is it the language's job to tell us what's acceptable and what's not?

it doesn't offer better support.

I disagree. D is a systems language first and foremost. Much of the rest can be done in library code. That isn't to say that I wouldn't like improved multiprogramming support in the language for the things that are awkward to do in library code (a thread-local storage class, for example), but trying to prevent the user from shooting himself in the foot is unnecessary. Particularly if doing so incurs a runtime cost that is not avoidable.
 But still, you're far better off than the current wild west
 approach where everything is implicitly shared with no protection
 whatsoever. The popular double checked locking bug will be
 impossible to code in D without stuffing in explicit casts. The
 casts will be a red flag that the programmer is making a mistake.

The double checked locking "bug" is only a bug on certain architectures, none of which D is supported on.

steadily moves towards the relaxed sequential consistency model. The threading model supported by Java and the upcoming C++0x release are both based on the relaxed model, that is clearly where the industry expects things to go, and I see no reason to believe otherwise.

There was some talk in the C++0x memory model discussion that Intel was actually planning on providing equivalent or stronger guarantees for future processors rather than weaker ones. I'll admit to having been very surprised at the time, but apparently they feel that they can do so and still provide the performance people expect. I guess the resounding failure of the Itanic forced them to rethink what was required for a successful new processor design. If I remember correctly, it was Paul McKenney that brought this up if you feel like searching the archives. Sean
Jul 31 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 In my opinion, the easiest way to describe the hardware side of things is
 simply to say that the CPU does the exact same thing as the optimizer in
 the compiler, only it does this dynamically as the code is executing.  The
 rest just involves ideas for how to constrain CPU and compiler optimizations
 so the app behaves as expected when concurrency is involved.  In your defense,
 "volatile" is a perfectly suitable minimum for D, so you did get the gist of
 the issue, even at the outset.  The catch is that, while "volatile" controls
 the compiler, you still need to control the CPU, so inline ASM is required
 as well.  Fortunately, D has that :-)  So please give yourself a bit more
 credit here.  D1 works perfectly well for concurrent programming.  It just
 support this is a sufficiently non-obvious way that only people who
 understand the issues involved are likely to realize it.  But as most of
 this stuff should really be in a library anyway, I don't see a problem
 with things as they are.

Java has synchronization and volatile, and it isn't good enough.
 Finding a way for the average user to do safe concurrent programming is an
 entirely different issue in my opinion, and has only really been "solved," in
 my opinion, in the functional programming realm.  And that's by eliminating
 data sharing--the bane of imperative languages everywhere.

D will eliminate implicit data sharing. To share data, you'll have to mark it as shared, and with the marking will come extra help in fences and synchronization. I've looked at the two classic multithreaded problems - double checked locking, and sequential consistency between threads. This model prevents both of them from happening.
 I disagree.  D is a systems language first and foremost.  Much of the
 rest can be done in library code.  That isn't to say that I wouldn't
 like improved multiprogramming support in the language for the things
 that are awkward to do in library code (a thread-local storage class,
 for example), but trying to prevent the user from shooting himself in
 the foot is unnecessary.
 Particularly if doing so incurs a runtime
 cost that is not avoidable.

It is avoidable if you're willing to insert a cast. Putting in the cast says "I know how to handle the wild west, let me do it." The cast has zero runtime cost.
 There was some talk in the C++0x memory model discussion that Intel
 was actually planning on providing equivalent or stronger guarantees
 for future processors rather than weaker ones.  I'll admit to having
 been very surprised at the time, but apparently they feel that they
 can do so and still provide the performance people expect.  I guess
 the resounding failure of the Itanic forced them to rethink what was
 required for a successful new processor design.  If I remember
 correctly, it was Paul McKenney that brought this up if you feel like
 searching the archives.

Intel may be reacting to the disastrous problems conventional languages have with this. If it is solved (and I think we have a credible solution), Intel may change their direction.
Jul 31 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Sean Kelly wrote:
 In my opinion, the easiest way to describe the hardware side of things is
 simply to say that the CPU does the exact same thing as the optimizer in
 the compiler, only it does this dynamically as the code is executing.  The
 rest just involves ideas for how to constrain CPU and compiler optimizations
 so the app behaves as expected when concurrency is involved.  In your defense,
 "volatile" is a perfectly suitable minimum for D, so you did get the gist of
 the issue, even at the outset.  The catch is that, while "volatile" controls
 the compiler, you still need to control the CPU, so inline ASM is required
 as well.  Fortunately, D has that :-)  So please give yourself a bit more
 credit here.  D1 works perfectly well for concurrent programming.  It just
 support this is a sufficiently non-obvious way that only people who
 understand the issues involved are likely to realize it.  But as most of
 this stuff should really be in a library anyway, I don't see a problem
 with things as they are.


But volatile in Java is completely different. And Java doesn't support inline ASM. That said, Java post JSR-133 (ie. Java today) is actually fine. The C++ 0x people simply didn't copy Java because the Java memory model is too strict to appease the performance-crazed folks in the group :-)
 Finding a way for the average user to do safe concurrent programming is an
 entirely different issue in my opinion, and has only really been "solved," in
 my opinion, in the functional programming realm.  And that's by eliminating
 data sharing--the bane of imperative languages everywhere.

mark it as shared, and with the marking will come extra help in fences and synchronization. I've looked at the two classic multithreaded problems - double checked locking, and sequential consistency between threads. This model prevents both of them from happening.

So "shared" will tell the compiler to automatically fence, etc? Will any actual enforcement be done? And if so, will this be at compile time, run time, or both?
 I disagree.  D is a systems language first and foremost.  Much of the
 rest can be done in library code.  That isn't to say that I wouldn't
 like improved multiprogramming support in the language for the things
 that are awkward to do in library code (a thread-local storage class,
 for example), but trying to prevent the user from shooting himself in
 the foot is unnecessary.
 Particularly if doing so incurs a runtime
 cost that is not avoidable.

says "I know how to handle the wild west, let me do it." The cast has zero runtime cost.

I think that cast is already used far too much as a standard programming mechanism in D 2.0. And I'll admit that I don't entirely understand why you don't like const_cast but assertUnique or whatever does exactly that behind the scenes. Should we consider cast to be an evil red flag-throwing feature or not?
 There was some talk in the C++0x memory model discussion that Intel
 was actually planning on providing equivalent or stronger guarantees
 for future processors rather than weaker ones.  I'll admit to having
 been very surprised at the time, but apparently they feel that they
 can do so and still provide the performance people expect.  I guess
 the resounding failure of the Itanic forced them to rethink what was
 required for a successful new processor design.  If I remember
 correctly, it was Paul McKenney that brought this up if you feel like
 searching the archives.

have with this. If it is solved (and I think we have a credible solution), Intel may change their direction.

That's certainly possible. But I do think it would require the solution to be pervasive rather than just in D if Intel were to pay attention. That said, I'd most prefer release consistency for a hardware memory model (somewhat like the Itanium) combined with hardware transactional memory. I'm actually a bit disappointed that the Itanium wasn't successful. The basic design was solid. Sean
Jul 31 2008
next sibling parent superdan <super dan.org> writes:
Sean Kelly Wrote:

 That's certainly possible.  But I do think it would require the solution to
 be pervasive rather than just in D if Intel were to pay attention.  That
 said, I'd most prefer release consistency for a hardware memory model
 (somewhat like the Itanium) combined with hardware transactional
 memory.  I'm actually a bit disappointed that the Itanium wasn't
 successful.  The basic design was solid.

haven't read bartosz' stuff yet, so no comment on that. but with all due respect. about itanium's design. what a piece of rotten shit that is. they use predicated execution like it's jesus on tv. of course that didn't catch up. itanium was a stillborn from day 1.
Jul 31 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 Java has synchronization and volatile, and it isn't good enough.

ASM. That said, Java post JSR-133 (ie. Java today) is actually fine. The C++ 0x people simply didn't copy Java because the Java memory model is too strict to appease the performance-crazed folks in the group :-)

From talking to people who do large scale multithreaded Java programs, it is not fine. The problem is that there is no way to look at a non-trivial piece of code that you didn't write, and determine if it has dependencies on sequential consistency or not. I'm not arguing that a thread expert cannot make a thread correct program in Java and C++. They can. The problem is the inability to verify such correctness, no help is available from the language, and the dearth of such experts.
 So "shared" will tell the compiler to automatically fence, etc?

Yes.
 Will any actual
 enforcement be done?  And if so, will this be at compile time, run time, or
 both?

Compile time - it's part of the static type checking system.
 It is avoidable if you're willing to insert a cast. Putting in the cast
 says "I know how to handle the wild west, let me do it." The cast has
 zero runtime cost.

mechanism in D 2.0. And I'll admit that I don't entirely understand why you don't like const_cast but assertUnique or whatever does exactly that behind the scenes. Should we consider cast to be an evil red flag-throwing feature or not?

Cast is the red flag raising feature. The thing about it is that when you review code, the cast is where you look for bugs. With Java and C++, you have *no clue* where to look for bugs. It reduces the problem domain from the entire program to a (hopefully) manageable small subset.
Jul 31 2008
next sibling parent reply superdan <super dan.org> writes:
Walter Bright Wrote:

 Sean Kelly wrote:
 Java has synchronization and volatile, and it isn't good enough.

ASM. That said, Java post JSR-133 (ie. Java today) is actually fine. The C++ 0x people simply didn't copy Java because the Java memory model is too strict to appease the performance-crazed folks in the group :-)

From talking to people who do large scale multithreaded Java programs, it is not fine. The problem is that there is no way to look at a non-trivial piece of code that you didn't write, and determine if it has dependencies on sequential consistency or not. I'm not arguing that a thread expert cannot make a thread correct program in Java and C++. They can. The problem is the inability to verify such correctness, no help is available from the language, and the dearth of such experts.
 So "shared" will tell the compiler to automatically fence, etc?

Yes.

yech. so i write this: ++a; ++b; ++c; and very different code comes down the pike depending on a or b or c being shared. not easy to clarify the code is correct. this ain't cool.
Jul 31 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
superdan wrote:
 Walter Bright Wrote:
 So "shared" will tell the compiler to automatically fence, etc?


yech. so i write this: ++a; ++b; ++c; and very different code comes down the pike depending on a or b or c being shared. not easy to clarify the code is correct. this ain't cool.

If conventional code were generated for i++, and i was accessed from multiple threads, the code is *broken*.
Jul 31 2008
next sibling parent reply superdan <super dan.org> writes:
Walter Bright Wrote:

 superdan wrote:
 Walter Bright Wrote:
 So "shared" will tell the compiler to automatically fence, etc?


yech. so i write this: ++a; ++b; ++c; and very different code comes down the pike depending on a or b or c being shared. not easy to clarify the code is correct. this ain't cool.

If conventional code were generated for i++, and i was accessed from multiple threads, the code is *broken*.

i grok that. my problem is that your shared doesn't help me with writing good code in that case. ++x is just wrong for shared x. i'd rather have it disabled or somethin'.
Jul 31 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
superdan wrote:
 i grok that. my problem is that your shared doesn't help me with
 writing good code in that case. ++x is just wrong for shared x. i'd
 rather have it disabled or somethin'.

Actually, the current plan is that ++ would be disabled for shared lvalues. Reads and writes to them would be done through intrinsic functions, which would make clear the order in which reads and writes are done. Sure, it won't be pretty, but there won't be any ambiguity of the order in which things happen.
Aug 01 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 superdan wrote:
 i grok that. my problem is that your shared doesn't help me with
 writing good code in that case. ++x is just wrong for shared x. i'd
 rather have it disabled or somethin'.

lvalues. Reads and writes to them would be done through intrinsic functions, which would make clear the order in which reads and writes are done. Sure, it won't be pretty, but there won't be any ambiguity of the order in which things happen.

A totally worthwhile tradeoff IMO. The alternative would be to have ++ call INC if supported or a CAS loop if not, and that's a hidden cost that may surprise users. It could always be enabled later if needed anyway. Oh, and darn you for getting me moderately enthusiastic for D 2.0 :-) Sean
Aug 01 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 Sure, it won't be pretty, but there won't be any ambiguity of the order
 in which things happen.

A totally worthwhile tradeoff IMO. The alternative would be to have ++ call INC if supported or a CAS loop if not, and that's a hidden cost that may surprise users. It could always be enabled later if needed anyway.

I'm surprised, we expected much more flak about that <g>. The idea is to screw everything down tight like this, see how it goes, and then experience will tell us where we need to loosen things up.
 Oh, and darn you for getting me moderately enthusiastic for
 D 2.0 :-)

I for one am very enthusiastic about the new threading model. The real validation would be when other languages start copying it!
Aug 01 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 superdan wrote:
 Walter Bright Wrote:
 So "shared" will tell the compiler to automatically fence, etc?


yech. so i write this: ++a; ++b; ++c; and very different code comes down the pike depending on a or b or c being shared. not easy to clarify the code is correct. this ain't cool.

multiple threads, the code is *broken*.

Not necessarily. If i is a 32-bit number and only one thread is doing the writing then the code could be perfectly safe. Sean
Aug 01 2008
next sibling parent reply superdan <super dan.org> writes:
Sean Kelly Wrote:

 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 superdan wrote:
 Walter Bright Wrote:
 So "shared" will tell the compiler to automatically fence, etc?


yech. so i write this: ++a; ++b; ++c; and very different code comes down the pike depending on a or b or c being shared. not easy to clarify the code is correct. this ain't cool.

multiple threads, the code is *broken*.

Not necessarily. If i is a 32-bit number and only one thread is doing the writing then the code could be perfectly safe. Sean

i don't think so. reading must be still fenced if at least one thread writes to it. walt is correct.
Aug 01 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from superdan (super dan.org)'s article
 Sean Kelly Wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 superdan wrote:
 Walter Bright Wrote:
 So "shared" will tell the compiler to automatically fence, etc?


yech. so i write this: ++a; ++b; ++c; and very different code comes down the pike depending on a or b or c being shared. not easy to clarify the code is correct. this ain't cool.

multiple threads, the code is *broken*.

Not necessarily. If i is a 32-bit number and only one thread is doing the writing then the code could be perfectly safe.


Yeah, but the "i++" is safe, which is all I was implying. Technically the read doesn't even need to be fenced so long as the reader doesn't care if they then operate on a stale value, but it's rare for that to be the case. However, I think I do use this approach in core.Thread in Tango for a flag somewhere. Kinda risky, but I don't want to pay for the ~70 cycles a lock would require and I really don't care if the value is a bit stale. But in these instances, I think it's totally okay to require the user to take extra steps to indicate that this is his intention. core.Atomic, for example, has msync.raw to indicate that no synchronization should occur, but a bidirectional fence is the default if no sync flag is passed. Sean
Aug 01 2008
parent reply superdan <super dan.org> writes:
Sean Kelly Wrote:

 == Quote from superdan (super dan.org)'s article
 Sean Kelly Wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 superdan wrote:
 Walter Bright Wrote:
 So "shared" will tell the compiler to automatically fence, etc?


yech. so i write this: ++a; ++b; ++c; and very different code comes down the pike depending on a or b or c being shared. not easy to clarify the code is correct. this ain't cool.

multiple threads, the code is *broken*.

Not necessarily. If i is a 32-bit number and only one thread is doing the writing then the code could be perfectly safe.


Yeah, but the "i++" is safe, which is all I was implying. Technically the read doesn't even need to be fenced so long as the reader doesn't care if they then operate on a stale value, but it's rare for that to be the case. However, I think I do use this approach in core.Thread in Tango for a flag somewhere. Kinda risky, but I don't want to pay for the ~70 cycles a lock would require and I really don't care if the value is a bit stale. But in these instances, I think it's totally okay to require the user to take extra steps to indicate that this is his intention. core.Atomic, for example, has msync.raw to indicate that no synchronization should occur, but a bidirectional fence is the default if no sync flag is passed.

makes sense. but i guess we agree that that is the rare case in which you're ok with a race. the usual case is you don't want a race. so i think it's fair that the rare case requires a cast. walt seems to have gotten the default right as far as i can tell.
Aug 01 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
superdan wrote:
 makes sense. but i guess we agree that that is the rare case in which
 you're ok with a race. the usual case is you don't want a race. so i
 think it's fair that the rare case requires a cast. walt seems to
 have gotten the default right as far as i can tell.

It's not just me. There are several people who've been hammering away at how this needs to work, including Andrei, Bartosz, David Held, Brad Roberts, and Eric Niebler.
Aug 01 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 If conventional code were generated for i++, and i was accessed from
 multiple threads, the code is *broken*.

Not necessarily. If i is a 32-bit number and only one thread is doing the writing then the code could be perfectly safe.

If you've got only one thread, why is it shared ? If it is shared, there's the possibility of multiple threads, and so the code is wrong wrong wrong.
Aug 01 2008
next sibling parent reply superdan <super dan.org> writes:
Walter Bright Wrote:

 Sean Kelly wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 If conventional code were generated for i++, and i was accessed from
 multiple threads, the code is *broken*.

Not necessarily. If i is a 32-bit number and only one thread is doing the writing then the code could be perfectly safe.

If you've got only one thread, why is it shared ? If it is shared, there's the possibility of multiple threads, and so the code is wrong wrong wrong.

i think he means a different case. you have many threads alright. but only one is incrementin'. others are just readin'.
Aug 01 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
superdan wrote:
 Walter Bright Wrote:
 
 Sean Kelly wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s
 article
 If conventional code were generated for i++, and i was accessed
 from multiple threads, the code is *broken*.

doing the writing then the code could be perfectly safe.

there's the possibility of multiple threads, and so the code is wrong wrong wrong.

i think he means a different case. you have many threads alright. but only one is incrementin'. others are just readin'.

If Sean means that the code is synchronized so only one thread has access, he is correct. In the proposed threading model, within a synchronized function, the shared object data can be accessed without fences and the ++ will work. Essentially, within a synchronized function, the 'this' object becomes tail-shared. I know, AAAIIIEEEEE!
Aug 01 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Sean Kelly wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 If conventional code were generated for i++, and i was accessed from
 multiple threads, the code is *broken*.

Not necessarily. If i is a 32-bit number and only one thread is doing the writing then the code could be perfectly safe.

there's the possibility of multiple threads, and so the code is wrong wrong wrong.

Only one writer, multiple readers. But this is assuming the INC is issued to the CPU rather than the compiler deciding to just hold onto the value in a register or something. ie. I think "shared" implies more than fences, yes? It's also an indication to the compiler than certain optimizations may not be performed, roughly similar to 'volatile' in D 1.0. Sean
Aug 01 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Sean Kelly wrote:
 Java has synchronization and volatile, and it isn't good enough.

ASM. That said, Java post JSR-133 (ie. Java today) is actually fine. The C++ 0x people simply didn't copy Java because the Java memory model is too strict to appease the performance-crazed folks in the group :-)

it is not fine. The problem is that there is no way to look at a non-trivial piece of code that you didn't write, and determine if it has dependencies on sequential consistency or not. I'm not arguing that a thread expert cannot make a thread correct program in Java and C++. They can. The problem is the inability to verify such correctness, no help is available from the language, and the dearth of such experts.

That's the problem with providing such fundamental support for lock-free programming: people will try it, and they'll invariably get it wrong. This is actually the reason why I like the minimalist approach of D 1.0 with 'volatile'. Support for lock-free is sufficiently subtle that it's unlikely to be used outside of library code.
 So "shared" will tell the compiler to automatically fence, etc?

 Will any actual
 enforcement be done?  And if so, will this be at compile time, run time, or
 both?


I've got to admit that I actually like this idea. It's a breaking change that will trigger run-time failures in code when the feature is deployed, but in the kind of multithreaded apps I write I'd be labeling perhaps two variable declarations in the entire app. Would it be possible to do something like this and have the compiler realize it's safe: class SharedObj { void go() {} } shared Mutex m; shared SharedObj o; static this() { m = new Mutex; o = new SharedObj; } void someFunc() { synchronized( m ) { o.go(); } }
 It is avoidable if you're willing to insert a cast. Putting in the cast
 says "I know how to handle the wild west, let me do it." The cast has
 zero runtime cost.

mechanism in D 2.0. And I'll admit that I don't entirely understand why you don't like const_cast but assertUnique or whatever does exactly that behind the scenes. Should we consider cast to be an evil red flag-throwing feature or not?

you review code, the cast is where you look for bugs. With Java and C++, you have *no clue* where to look for bugs. It reduces the problem domain from the entire program to a (hopefully) manageable small subset.

Java and C++ have cast too, though. Unfortunately, it's not easy to grep for 'cast' in Java because of the syntax, but I use the C++ style casts religiously there and I like that they "jump out" at me when reading the code. From a quick scan of an old project of mine, outside systems code where casting is often necessary as a matter of course, the precious few casts in the app are mostly for warning-free comparisons of signed and unsigned integers in situations I know the values will be in bounds. Which reminds me... weren't we going to get tighter conversion rules for concrete types? I'd love to have the D compiler yell at me for these things like my C++ compiler does. Back on track... I suppose I'm just worried that my apps will end up with casts all over the place simply to allow me to operate normally, thus diluting the usefulness of this red flag. But that's idle speculation so perhaps my concern is unfounded.
Jul 31 2008
next sibling parent reply superdan <super dan.org> writes:
Sean Kelly Wrote:

 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Sean Kelly wrote:
 Java has synchronization and volatile, and it isn't good enough.

ASM. That said, Java post JSR-133 (ie. Java today) is actually fine. The C++ 0x people simply didn't copy Java because the Java memory model is too strict to appease the performance-crazed folks in the group :-)

it is not fine. The problem is that there is no way to look at a non-trivial piece of code that you didn't write, and determine if it has dependencies on sequential consistency or not. I'm not arguing that a thread expert cannot make a thread correct program in Java and C++. They can. The problem is the inability to verify such correctness, no help is available from the language, and the dearth of such experts.

That's the problem with providing such fundamental support for lock-free programming: people will try it, and they'll invariably get it wrong. This is actually the reason why I like the minimalist approach of D 1.0 with 'volatile'. Support for lock-free is sufficiently subtle that it's unlikely to be used outside of library code.

fraid you might have a slightly specialized definition of what lock-free code is. i think you say that cas-based shit is lock free. but here, this is lock free: data = 5.4; dataThere = true; people use lock-free *everywhere*. just they don't call it that way. they just synchronize through atomic assignments. i'm not sure at this point how d's shared will improve the above. if i understand that shit correctly you define data and dataThere as shared. then you know assignments occur in the proper sequence (because of the inserted fences and shit). if they weren't shared they could be assigned in the wrong order but nobody could tell. it's like the shit in the forest that don't stink because nobody's smellin'. and if they weren't shared they wouldn't be shareable to start with. so the whole shit works. is that true walt?
 So "shared" will tell the compiler to automatically fence, etc?

 Will any actual
 enforcement be done?  And if so, will this be at compile time, run time, or
 both?


I've got to admit that I actually like this idea. It's a breaking change that will trigger run-time failures in code when the feature is deployed, but in the kind of multithreaded apps I write I'd be labeling perhaps two variable declarations in the entire app.

yeh same here. good mt apps share little and with care.
  Would it be possible to do
 something like this and have the compiler realize it's safe:
 
     class SharedObj
     {
         void go() {}
     }
 
     shared Mutex m;
     shared SharedObj o;
 
     static this()
     {
         m = new Mutex;
         o = new SharedObj;
     }
 
     void someFunc()
     {
         synchronized( m )
         {
             o.go();
         }
     }
 
 It is avoidable if you're willing to insert a cast. Putting in the cast
 says "I know how to handle the wild west, let me do it." The cast has
 zero runtime cost.

mechanism in D 2.0. And I'll admit that I don't entirely understand why you don't like const_cast but assertUnique or whatever does exactly that behind the scenes. Should we consider cast to be an evil red flag-throwing feature or not?

you review code, the cast is where you look for bugs. With Java and C++, you have *no clue* where to look for bugs. It reduces the problem domain from the entire program to a (hopefully) manageable small subset.

Java and C++ have cast too, though. Unfortunately, it's not easy to grep for 'cast' in Java because of the syntax, but I use the C++ style casts religiously there and I like that they "jump out" at me when reading the code. From a quick scan of an old project of mine, outside systems code where casting is often necessary as a matter of course, the precious few casts in the app are mostly for warning-free comparisons of signed and unsigned integers in situations I know the values will be in bounds. Which reminds me... weren't we going to get tighter conversion rules for concrete types? I'd love to have the D compiler yell at me for these things like my C++ compiler does.

fuck yeah walt. put me down for that one too.
Jul 31 2008
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
superdan wrote:
 fraid you might have a slightly specialized definition of what
 lock-free code is. i think you say that cas-based shit is lock free.
 but here, this is lock free:
 
 data = 5.4; dataThere = true;
 
 people use lock-free *everywhere*. just they don't call it that way.
 they just synchronize through atomic assignments.
 
 i'm not sure at this point how d's shared will improve the above. if
 i understand that shit correctly you define data and dataThere as
 shared. then you know assignments occur in the proper sequence
 (because of the inserted fences and shit). if they weren't shared
 they could be assigned in the wrong order but nobody could tell. it's
 like the shit in the forest that don't stink because nobody's
 smellin'. and if they weren't shared they wouldn't be shareable to
 start with. so the whole shit works. is that true walt?

Yes.
Aug 01 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from superdan (super dan.org)'s article
 Sean Kelly Wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Sean Kelly wrote:
 Java has synchronization and volatile, and it isn't good enough.

ASM. That said, Java post JSR-133 (ie. Java today) is actually fine. The C++ 0x people simply didn't copy Java because the Java memory model is too strict to appease the performance-crazed folks in the group :-)

it is not fine. The problem is that there is no way to look at a non-trivial piece of code that you didn't write, and determine if it has dependencies on sequential consistency or not. I'm not arguing that a thread expert cannot make a thread correct program in Java and C++. They can. The problem is the inability to verify such correctness, no help is available from the language, and the dearth of such experts.

That's the problem with providing such fundamental support for lock-free programming: people will try it, and they'll invariably get it wrong. This is actually the reason why I like the minimalist approach of D 1.0 with 'volatile'. Support for lock-free is sufficiently subtle that it's unlikely to be used outside of library code.


 data = 5.4;
 dataThere = true;
 people use lock-free *everywhere*. just they don't call it that way. they just

Yeah that's true. What drives me crazy about this is that there's no way to tell from inspection whether the programmer knew what they were doing. You end up having to check all the uses of 'data' to find out. I guess this is Walter's point about static checking. If 'data' were shared then I could trust that it would "just work." In Tango, you'd do: atomicStore( data, 5.4 ); And that would label the assignment as "safe" to a reader, but other uses of 'data' could still be broken.
 i'm not sure at this point how d's shared will improve the above. if i

know assignments occur in the proper sequence (because of the inserted fences and shit). if they weren't shared they could be assigned in the wrong order but nobody could tell. it's like the shit in the forest that don't stink because nobody's smellin'. and if they weren't shared they wouldn't be shareable to start with. so the whole shit works. is that true walt? This sounds right. My only concern for the injected fences is that it won't always result in optimal code for what the user is doing. But it will be safe, which I guess is pretty important (by "optimal" I mean that you don't always need fences for an operation depending on the hardware and on whether you care about code movement across the operation). Sean
Aug 01 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 This sounds right.  My only concern for the injected fences is that it won't
always
 result in optimal code for what the user is doing.  But it will be safe, which
I
 guess is pretty important (by "optimal" I mean that you don't always need
fences
 for an operation depending on the hardware and on whether you care about code
 movement across the operation).

You're right, it won't always be optimal. The idea is to get it right and then just optimize the bottlenecks.
Aug 02 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 Would it be possible to do
 something like this and have the compiler realize it's safe:
 
     class SharedObj
     {
         void go() {}
     }
 
     shared Mutex m;
     shared SharedObj o;
 
     static this()
     {
         m = new Mutex;
         o = new SharedObj;
     }
 
     void someFunc()
     {
         synchronized( m )
         {
             o.go();
         }
     }

I don't know, but I doubt it.
 Cast is the red flag raising feature. The thing about it is that when
 you review code, the cast is where you look for bugs. With Java and C++,
 you have *no clue* where to look for bugs. It reduces the problem domain
 from the entire program to a (hopefully) manageable small subset.

Java and C++ have cast too, though.

But that is useless for multithreading, because Java and C++ types have no notion of sharing.
 Which
 reminds me... weren't we going to get tighter conversion rules for concrete
 types?  I'd love to have the D compiler yell at me for these things like my
 C++ compiler does.

All in goood time, my pretty <rubs hands>
 Back on track... I suppose I'm just worried that my apps will end up with
 casts all over the place simply to allow me to operate normally, thus
 diluting the usefulness of this red flag.  But that's idle speculation
 so perhaps my concern is unfounded.

I don't know how it will work out yet in practice, either. But I suspect if casts wind up all over the place, that may be a sign that there are too many connection points between the shared and unshared worlds, and perhaps a code refactoring is in order.
Jul 31 2008
prev sibling parent reply superdan <super dan.org> writes:
Sean Kelly Wrote:

 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Sean Kelly wrote:
 In my opinion, the easiest way to describe the hardware side of things is
 simply to say that the CPU does the exact same thing as the optimizer in
 the compiler, only it does this dynamically as the code is executing.  The
 rest just involves ideas for how to constrain CPU and compiler optimizations
 so the app behaves as expected when concurrency is involved.  In your defense,
 "volatile" is a perfectly suitable minimum for D, so you did get the gist of
 the issue, even at the outset.  The catch is that, while "volatile" controls
 the compiler, you still need to control the CPU, so inline ASM is required
 as well.  Fortunately, D has that :-)  So please give yourself a bit more
 credit here.  D1 works perfectly well for concurrent programming.  It just
 support this is a sufficiently non-obvious way that only people who
 understand the issues involved are likely to realize it.  But as most of
 this stuff should really be in a library anyway, I don't see a problem
 with things as they are.


But volatile in Java is completely different. And Java doesn't support inline ASM. That said, Java post JSR-133 (ie. Java today) is actually fine. The C++ 0x people simply didn't copy Java because the Java memory model is too strict to appease the performance-crazed folks in the group :-)

i'm afraid c++ and c++0x and java are "actually fine" to write multiprocessing code if the coder is fucking superman on steroids after an overdose of ritalin. as far as threads are concerned these are as good as brainfuck to code in. you also say d1 is perfectly fine to do multiprocessing in. i think that's at best naive. sorry sean.
Jul 31 2008
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from superdan (super dan.org)'s article
 Sean Kelly Wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Sean Kelly wrote:
 In my opinion, the easiest way to describe the hardware side of things is
 simply to say that the CPU does the exact same thing as the optimizer in
 the compiler, only it does this dynamically as the code is executing.  The
 rest just involves ideas for how to constrain CPU and compiler optimizations
 so the app behaves as expected when concurrency is involved.  In your defense,
 "volatile" is a perfectly suitable minimum for D, so you did get the gist of
 the issue, even at the outset.  The catch is that, while "volatile" controls
 the compiler, you still need to control the CPU, so inline ASM is required
 as well.  Fortunately, D has that :-)  So please give yourself a bit more
 credit here.  D1 works perfectly well for concurrent programming.  It just
 support this is a sufficiently non-obvious way that only people who
 understand the issues involved are likely to realize it.  But as most of
 this stuff should really be in a library anyway, I don't see a problem
 with things as they are.


But volatile in Java is completely different. And Java doesn't support inline ASM. That said, Java post JSR-133 (ie. Java today) is actually fine. The C++ 0x people simply didn't copy Java because the Java memory model is too strict to appease the performance-crazed folks in the group :-)


far as threads are concerned these are as good as brainfuck to code in. you also say d1 is perfectly fine to do multiprocessing in. i think that's at best naive. sorry sean. No problem. Just because I think they're all functional doesn't mean I think they make for easily verifiable or safe code. I'd agree with you that most actual multithreaded code in these languages is garbage. Though most plain old code I've seen is garbage anyway, so I guess it's no surprise that the actually difficult stuff would follow suit. As far as verifiability is concerned though, CSP and the other process algebras are darn nice. Sean
Jul 31 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
superdan wrote:
 i'm afraid c++ and c++0x and java are "actually fine" to write
 multiprocessing code if the coder is fucking superman on steroids
 after an overdose of ritalin.

There's also the issue of the person who thinks they know how to write multithreaded code, but don't. Want an example? Just look at some of my older code. This code may "work" well enough that the problems don't appear until years later. Then what? I remember the reaction to Herb Sutter showing some of the things that can go wrong to multithreaded programmers - it was holy ****, I had no idea! Having no compiler help with this is like turning off static type checking. Sure, if you're a good programmer, you don't need static type checking! I believe there is a growing need to be able to statically *prove* things about a program. If that can be done, you don't have to rely on experts being always right. Java, for example, can prove your program is memory safe. Certain classes of bugs cannot happen with Java programs. The more classes of bugs that can be defined out of existence, the easier it will be to verify correctness regardless of the expertise of the programmer.
Jul 31 2008
parent reply JAnderson <ask me.com> writes:
Walter Bright wrote:
 Having no compiler help with this is like turning off static type 
 checking. Sure, if you're a good programmer, you don't need static type 
 checking!
 

Lets all just program in Python or one of those other untypesafe languages :) -Joel
Jul 31 2008
parent superdan <super dan.org> writes:
JAnderson Wrote:

 Walter Bright wrote:
 Having no compiler help with this is like turning off static type 
 checking. Sure, if you're a good programmer, you don't need static type 
 checking!
 

Lets all just program in Python or one of those other untypesafe languages :)

python is typesafe. just not statically.
Jul 31 2008
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 Java has synchronization and volatile, and it isn't good enough.

Java is some years old, while Scala is a new language that runs on the JavaVM that is slowly growing in its usage. In Scala people often use Actor-based concurrency (and someone is starting to use Actors in Java too). Scala contains some 'modern' things, that D may take a look at, instead of using just C/C++/C++0x/Java/Python as reference. Bye, bearophile
Jul 31 2008
prev sibling next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Walter Bright, el 30 de julio a las 23:22 me escribiste:
 Steven Schveighoffer wrote:
"Walter Bright" wrote
http://www.reddit.com/comments/6u7k0/sharing_in_d/

First, that the default is 'unshared'. This is going to break a lot of existing code, and make peoples lives miserable who do not want to deal with unshared non-stack data.

Nearly all global data is assumed to be and treated as if it were unshared. So making unshared the default is the right solution. And frankly, if you're using a lot of global variables, you might want to reevaluate what you're doing. Lots of global variables is the 80's style of programming :-)

Tell that to singleton-monkeys =P -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- ¿Qué será lo que hace que una brújula siempre marque el norte? - Ser aguja, nada más, y cumplir su misión. -- Ricardo Vaporeso
Jul 31 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Leandro Lucarella wrote:
 Tell that to singleton-monkeys =P

Yeah, and singletons suffer from the double-checked locking bug! Bartosz even found one of those in my code, and I should know better!
Jul 31 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Walter Bright" wrote
 Steven Schveighoffer wrote:
 "Walter Bright" wrote
 http://www.reddit.com/comments/6u7k0/sharing_in_d/

There are 2 problems I see with this scheme. First, that the default is 'unshared'. This is going to break a lot of existing code, and make peoples lives miserable who do not want to deal with unshared non-stack data.

Nearly all global data is assumed to be and treated as if it were unshared. So making unshared the default is the right solution. And frankly, if you're using a lot of global variables, you might want to reevaluate what you're doing. Lots of global variables is the 80's style of programming :-)

I have no idea where you came up with this. To me global means shared. Global means the world can see it, meaning that it's shared between all. Even VB.net uses 'Shared' as the keyword to mean 'global'
 I would hazard to guess that adopting this would cause a larger rift than 
 const.

Perhaps. But the alternative is the current wild west approach to multithreaded programming. With the proliferation of multicore computers, the era where this is acceptable is coming to an end.

Yeah, because all us cowboys don't like your kind. Maybe we need to get us a rope and have a lynchin. Seriously, how can you say that the current threadding tools are 'uncontrolled' (i.e. wild west)? I spend lots of time thinking about multithreadded issues, and make sure my software works properly. I think the level of quality for threadding issues depends on the coder, not the tools. In the case of shared/unshared, it's not going to change anything, except now I have to declare things I didn't have to declare before. I.e. having shared/unshared is going to be just as wild as before. I may be wrong, and this shared/unshared thing will be really great for people. But I think it needs a lot of work before it's helpful. In its current incarnation, I'll call it the 'shared wild west' approach :P
 Second, the fact that you can't implicitly cast shared to unshared and 
 vice versa.  It's going to make communication between both 'worlds' very 
 error prone, as you will be required to cast for any call from one to the 
 other.

I think the reverse is true. Moving data between those worlds is dangerous and needs to be carefully vetted, so requiring an explicit cast will reduce the chance of this happening unintentionally.

Except now instead of the compiler helping you, you have pushed aside that help and said 'I know what I'm doing'. Oops, back to the wild west :)
 People will do this just to get their code to work, without thinking 
 about the consequences.

True, but having it happen implicitly is even worse, because there's no indication that it is happening.

dmd mycode.d Error: when calling foo(shared int *), cannot pass int * edit mycode.d, cast to shared int * OK, now it works :) Probably without any problems, because the compiler has no idea whether I'm going to change it in another thread. Hell, I might not even HAVE more than one thread! But the result is, we're back to the same model as before. And now I have to cast everything. Annoying.
 Even those that do think about the consequences, can't have the compiler 
 statically check the cast in either direction, so once you cast, you lose 
 all the benefit.

But still, you're far better off than the current wild west approach where everything is implicitly shared with no protection whatsoever. The popular double checked locking bug will be impossible to code in D without stuffing in explicit casts. The casts will be a red flag that the programmer is making a mistake.

Please let me decide whether I'm far better off. I don't need protection from stuff that doesn't matter. I will still have to lock shared data, and still have to cast to get things to work, so I'm not better off. You can't tell me otherwise, because all this stuff is a figment of your imagination. You have no proof. Until you can show me that I'm better off with an actual example, then I believe we both are equally right :) -Steve
Jul 31 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:
 "Walter Bright" wrote
 Nearly all global data is assumed to be and treated as if it were 
 unshared. So making unshared the default is the right solution. And 
 frankly, if you're using a lot of global variables, you might want to 
 reevaluate what you're doing. Lots of global variables is the 80's style 
 of programming :-)

Global means the world can see it, meaning that it's shared between all. Even VB.net uses 'Shared' as the keyword to mean 'global'

The idea is that encapsulation is better, and having something shared between everyone violates encapsulation. When you have a global variable 'int x' that everyone can read and write to, and there's a bug, you have the whole program to search for that bug. The principle of encapsulation is that each chunk of data is visible only to the code that needs to see it, and no more. (Programming languages started out with everything being global data, and has moved away from that ever since.)
 Yeah, because all us cowboys don't like your kind.  Maybe we need to get us 
 a rope and have a lynchin.  Seriously, how can you say that the current 
 threadding tools are 'uncontrolled' (i.e. wild west)?

Because of the common multithreaded bug http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html for one example. There is no threading tool I'm aware of that can prevent or detect such bugs.
 I spend lots of time 
 thinking about multithreadded issues, and make sure my software works 
 properly.  I think the level of quality for threadding issues depends on the 
 coder, not the tools.

I believe the tools can make it easier.
 In the case of shared/unshared, it's not going to 
 change anything, except now I have to declare things I didn't have to 
 declare before.  I.e. having shared/unshared is going to be just as wild as 
 before.

Why? First of all, unshared data isn't going to have sequential or sync issues, by definition. Already, you've cut the problem domain down by a huge chunk. Next, shared data access will come with fences or sync. That isn't going to guarantee no deadlocks, but it will guarantee sequential consistency, and at the very least will dramatically cut the problem domain down.
 Except now instead of the compiler helping you, you have pushed aside that 
 help and said 'I know what I'm doing'.  Oops, back to the wild west :)

If you want the wild west, you have it, if you want compiler help instead, you got it. How is that worse than C++ or Java, where you always have the wild west and no help at all?
 True, but having it happen implicitly is even worse, because there's no 
 indication that it is happening.

dmd mycode.d Error: when calling foo(shared int *), cannot pass int * edit mycode.d, cast to shared int * OK, now it works :) Probably without any problems, because the compiler has no idea whether I'm going to change it in another thread. Hell, I might not even HAVE more than one thread! But the result is, we're back to the same model as before. And now I have to cast everything. Annoying.

Non-shared can be implicitly cast to shared, as that is always safe. Just not the other way.
 Please let me decide whether I'm far better off.

Ok. D offers both - and for the guy maintaining your code, there'll at least be clear indications of where to look for the source of elusive threading bugs. Optlink currently has a threading bug in it. I have no idea where to look for it in the source code.
 I don't need protection 
 from stuff that doesn't matter.  I will still have to lock shared data, and 
 still have to cast to get things to work, so I'm not better off.  You can't 
 tell me otherwise, because all this stuff is a figment of your imagination. 
 You have no proof.  Until you can show me that I'm better off with an actual 
 example, then I believe we both are equally right :)

I didn't think I'd convince anyone the first time around. But I'm patient <g>.
Jul 31 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Walter Bright" wrote
 Steven Schveighoffer wrote:
 "Walter Bright" wrote
 Nearly all global data is assumed to be and treated as if it were 
 unshared. So making unshared the default is the right solution. And 
 frankly, if you're using a lot of global variables, you might want to 
 reevaluate what you're doing. Lots of global variables is the 80's style 
 of programming :-)

Global means the world can see it, meaning that it's shared between all. Even VB.net uses 'Shared' as the keyword to mean 'global'

The idea is that encapsulation is better, and having something shared between everyone violates encapsulation. When you have a global variable 'int x' that everyone can read and write to, and there's a bug, you have the whole program to search for that bug. The principle of encapsulation is that each chunk of data is visible only to the code that needs to see it, and no more.

So if I write: shared int x; As a global variable, how does this help encapsulation? In the current model, if you need shared data, you use global variables. If you don't need shared data, use member or stack variables. My point is that what you will have done is just made the person who wants a global variable write 'shared' in front of it. I don't see how this helps him protect the variable at all. It just seems like you are enforcing something that already can be enforced.
 (Programming languages started out with everything being global data, and 
 has moved away from that ever since.)

I'm not advocating using global variables over stack or member variables. All I'm saying is that this 'shared/unshared' model doesn't seem to me like it will eliminate the need for threading constructs, or even help with it.
 Yeah, because all us cowboys don't like your kind.  Maybe we need to get 
 us a rope and have a lynchin.  Seriously, how can you say that the 
 current threadding tools are 'uncontrolled' (i.e. wild west)?

Because of the common multithreaded bug http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html for one example. There is no threading tool I'm aware of that can prevent or detect such bugs.

As described on that page, the problem was fixed with JDK 5, and can be solved using the volatile modifier.
 I spend lots of time thinking about multithreadded issues, and make sure 
 my software works properly.  I think the level of quality for threadding 
 issues depends on the coder, not the tools.

I believe the tools can make it easier.

I do too. But I don't see this one being that tool.
 In the case of shared/unshared, it's not going to change anything, except 
 now I have to declare things I didn't have to declare before.  I.e. 
 having shared/unshared is going to be just as wild as before.

Why? First of all, unshared data isn't going to have sequential or sync issues, by definition. Already, you've cut the problem domain down by a huge chunk. Next, shared data access will come with fences or sync. That isn't going to guarantee no deadlocks, but it will guarantee sequential consistency, and at the very least will dramatically cut the problem domain down.

Are you saying that there will be an automatic notion by the compiler that implements the fences, or that I have to add them on top? If the former, then I don't remember reading that in the article, and that does sound promising.
 Except now instead of the compiler helping you, you have pushed aside 
 that help and said 'I know what I'm doing'.  Oops, back to the wild west 
 :)

If you want the wild west, you have it, if you want compiler help instead, you got it. How is that worse than C++ or Java, where you always have the wild west and no help at all?

What I'm saying is that if you have to cast just to get something working, you have defeated the system. I'm not saying that you are back to the wild west *by choice*, I'm saying you will most likely end up having to do that just to get it to work. I'm thinking of many cases where you have to use old code, or old libraries that don't have this feature, or code written by someone unaware of the details.
 True, but having it happen implicitly is even worse, because there's no 
 indication that it is happening.

dmd mycode.d Error: when calling foo(shared int *), cannot pass int * edit mycode.d, cast to shared int * OK, now it works :) Probably without any problems, because the compiler has no idea whether I'm going to change it in another thread. Hell, I might not even HAVE more than one thread! But the result is, we're back to the same model as before. And now I have to cast everything. Annoying.

Non-shared can be implicitly cast to shared, as that is always safe. Just not the other way.

How is that possible? shared int *x; void foo(shared int *y) { x = y; } int *x2; void bar() { foo(x2); } After calling bar, isn't x2 now both shared (as x) and unshared at the same time? I think you need casts for both ways. I think shared/unshared is analogous to mutable/invariant. There is no implicit cast.
 Please let me decide whether I'm far better off.

Ok. D offers both - and for the guy maintaining your code, there'll at least be clear indications of where to look for the source of elusive threading bugs.

All I was saying with that comment is the notion that 'Walter knows best' is not a convincing argument.
 Optlink currently has a threading bug in it. I have no idea where to look 
 for it in the source code.

Threading problems are very difficult to find. I don't think the shared/unshared model will help with that, especially since most likely you will have to break it to get things working. I generally can only find multithreading issues with lots of logging, and running through potentially offending code in my head. I think that this idea has potential, and could possibly lead to something that is helpful. The thinking is in the right direction. But I'm not convinced that this incarnation will be helpful. I'd have to see examples of how this would be useful to understand it better. And please PLEASE make it backwards compatible. I don't see any reason why it must be shared that is the tagged value. -Steve
Aug 01 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 "Walter Bright" wrote
 Steven Schveighoffer wrote:
 "Walter Bright" wrote
 Nearly all global data is assumed to be and treated as if it were
 unshared. So making unshared the default is the right solution. And
 frankly, if you're using a lot of global variables, you might want to
 reevaluate what you're doing. Lots of global variables is the 80's style
 of programming :-)

Global means the world can see it, meaning that it's shared between all. Even VB.net uses 'Shared' as the keyword to mean 'global'

The idea is that encapsulation is better, and having something shared between everyone violates encapsulation. When you have a global variable 'int x' that everyone can read and write to, and there's a bug, you have the whole program to search for that bug. The principle of encapsulation is that each chunk of data is visible only to the code that needs to see it, and no more.

shared int x; As a global variable, how does this help encapsulation? In the current model, if you need shared data, you use global variables. If you don't need shared data, use member or stack variables. My point is that what you will have done is just made the person who wants a global variable write 'shared' in front of it. I don't see how this helps him protect the variable at all. It just seems like you are enforcing something that already can be enforced.
 (Programming languages started out with everything being global data, and
 has moved away from that ever since.)

All I'm saying is that this 'shared/unshared' model doesn't seem to me like it will eliminate the need for threading constructs, or even help with it.

I'm hoping that 'shared' will force programmers to think about what they're doing a bit more. A typical multithreaded app should have extremely little shared data. One thing I'm not sure of, though, is if I write a single- threaded app, will I need to label anything shared? Functionally I don't, since having everything thread-local is exactly what I need, but I'm not sure if the compiler will yell at me anyway. I'm guessing it will, which would be a bit annoying, but it would "future proof" the app for adding multithreading later, so perhaps it's okay. Sean
Aug 01 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Sean Kelly" wrote
 == Quote from Steven Schveighoffer article
 "Walter Bright" wrote
 Steven Schveighoffer wrote:
 "Walter Bright" wrote
 Nearly all global data is assumed to be and treated as if it were
 unshared. So making unshared the default is the right solution. And
 frankly, if you're using a lot of global variables, you might want to
 reevaluate what you're doing. Lots of global variables is the 80's 
 style
 of programming :-)

shared. Global means the world can see it, meaning that it's shared between all. Even VB.net uses 'Shared' as the keyword to mean 'global'

The idea is that encapsulation is better, and having something shared between everyone violates encapsulation. When you have a global variable 'int x' that everyone can read and write to, and there's a bug, you have the whole program to search for that bug. The principle of encapsulation is that each chunk of data is visible only to the code that needs to see it, and no more.

shared int x; As a global variable, how does this help encapsulation? In the current model, if you need shared data, you use global variables. If you don't need shared data, use member or stack variables. My point is that what you will have done is just made the person who wants a global variable write 'shared' in front of it. I don't see how this helps him protect the variable at all. It just seems like you are enforcing something that already can be enforced.
 (Programming languages started out with everything being global data, 
 and
 has moved away from that ever since.)

All I'm saying is that this 'shared/unshared' model doesn't seem to me like it will eliminate the need for threading constructs, or even help with it.

I'm hoping that 'shared' will force programmers to think about what they're doing a bit more. A typical multithreaded app should have extremely little shared data. One thing I'm not sure of, though, is if I write a single- threaded app, will I need to label anything shared? Functionally I don't, since having everything thread-local is exactly what I need, but I'm not sure if the compiler will yell at me anyway. I'm guessing it will, which would be a bit annoying, but it would "future proof" the app for adding multithreading later, so perhaps it's okay.

I'm thinking more in the case of functions. If I have a function foo, and I want to pass my shared data version to it, I need to re-implement foo with the parameters as being shared. Imagine a function with several parameters, in which you want to pass a combination of shared/unshared. That's 2^n variations you have to write. I think at the very least, for this to be palatable, there needs to be another modifier that unifies shared and unshared. Similar to how const unifies mutable and invariant. -Steve
Aug 01 2008
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 "Sean Kelly" wrote
 == Quote from Steven Schveighoffer article
 "Walter Bright" wrote
 Steven Schveighoffer wrote:
 "Walter Bright" wrote
 Nearly all global data is assumed to be and treated as if it were
 unshared. So making unshared the default is the right solution. And
 frankly, if you're using a lot of global variables, you might want to
 reevaluate what you're doing. Lots of global variables is the 80's
 style
 of programming :-)

shared. Global means the world can see it, meaning that it's shared between all. Even VB.net uses 'Shared' as the keyword to mean 'global'

The idea is that encapsulation is better, and having something shared between everyone violates encapsulation. When you have a global variable 'int x' that everyone can read and write to, and there's a bug, you have the whole program to search for that bug. The principle of encapsulation is that each chunk of data is visible only to the code that needs to see it, and no more.

shared int x; As a global variable, how does this help encapsulation? In the current model, if you need shared data, you use global variables. If you don't need shared data, use member or stack variables. My point is that what you will have done is just made the person who wants a global variable write 'shared' in front of it. I don't see how this helps him protect the variable at all. It just seems like you are enforcing something that already can be enforced.
 (Programming languages started out with everything being global data,
 and
 has moved away from that ever since.)

All I'm saying is that this 'shared/unshared' model doesn't seem to me like it will eliminate the need for threading constructs, or even help with it.

I'm hoping that 'shared' will force programmers to think about what they're doing a bit more. A typical multithreaded app should have extremely little shared data. One thing I'm not sure of, though, is if I write a single- threaded app, will I need to label anything shared? Functionally I don't, since having everything thread-local is exactly what I need, but I'm not sure if the compiler will yell at me anyway. I'm guessing it will, which would be a bit annoying, but it would "future proof" the app for adding multithreading later, so perhaps it's okay.

want to pass my shared data version to it, I need to re-implement foo with the parameters as being shared. Imagine a function with several parameters, in which you want to pass a combination of shared/unshared. That's 2^n variations you have to write.

Darnit, you're right. That's just like 'volatile' in C++. In fact, it's the primary reason why I dislike the const system in D 2.0.
 I think at the very least, for this to be palatable, there needs to be
 another modifier that unifies shared and unshared.  Similar to how const
 unifies mutable and invariant.

You could be right. Though that means yet another label and all the baggage that goes with it. Sean
Aug 01 2008
prev sibling parent reply superdan <super dan.org> writes:
Steven Schveighoffer Wrote:

 "Sean Kelly" wrote
 == Quote from Steven Schveighoffer article
 "Walter Bright" wrote
 Steven Schveighoffer wrote:
 "Walter Bright" wrote
 Nearly all global data is assumed to be and treated as if it were
 unshared. So making unshared the default is the right solution. And
 frankly, if you're using a lot of global variables, you might want to
 reevaluate what you're doing. Lots of global variables is the 80's 
 style
 of programming :-)

shared. Global means the world can see it, meaning that it's shared between all. Even VB.net uses 'Shared' as the keyword to mean 'global'

The idea is that encapsulation is better, and having something shared between everyone violates encapsulation. When you have a global variable 'int x' that everyone can read and write to, and there's a bug, you have the whole program to search for that bug. The principle of encapsulation is that each chunk of data is visible only to the code that needs to see it, and no more.

shared int x; As a global variable, how does this help encapsulation? In the current model, if you need shared data, you use global variables. If you don't need shared data, use member or stack variables. My point is that what you will have done is just made the person who wants a global variable write 'shared' in front of it. I don't see how this helps him protect the variable at all. It just seems like you are enforcing something that already can be enforced.
 (Programming languages started out with everything being global data, 
 and
 has moved away from that ever since.)

All I'm saying is that this 'shared/unshared' model doesn't seem to me like it will eliminate the need for threading constructs, or even help with it.

I'm hoping that 'shared' will force programmers to think about what they're doing a bit more. A typical multithreaded app should have extremely little shared data. One thing I'm not sure of, though, is if I write a single- threaded app, will I need to label anything shared? Functionally I don't, since having everything thread-local is exactly what I need, but I'm not sure if the compiler will yell at me anyway. I'm guessing it will, which would be a bit annoying, but it would "future proof" the app for adding multithreading later, so perhaps it's okay.

I'm thinking more in the case of functions. If I have a function foo, and I want to pass my shared data version to it, I need to re-implement foo with the parameters as being shared. Imagine a function with several parameters, in which you want to pass a combination of shared/unshared. That's 2^n variations you have to write.

but the code there *is* different. there are fence combinations & shit. i guess in such cases you'd need a template.
 I think at the very least, for this to be palatable, there needs to be 
 another modifier that unifies shared and unshared.  Similar to how const 
 unifies mutable and invariant.

sounds interesting but i don't get it. we have: invariant == never changes const == i won't change it mutable == fuck you, i'm changing in the shared cases we have: unshared == never seen by 2 threads ? == ? shared == fuck you, i'm shared so how would that go. i won't share it? i won't write to it? (that's useless bc of read fences.) anyway this is intriguing shit. unification is power.
Aug 01 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from superdan (super dan.org)'s article
 in the shared cases we have:
 unshared == never seen by 2 threads
 ? == ?
 shared == fuck you, i'm shared
 so how would that go. i won't share it? i won't write to it? (that's useless
bc of read fences.) anyway

Yeah, the idea of having a unifying label makes some sense, but I haven't been able to figure out what it would mean in terms of behavior. Maybe the middle one would be volatile in that the compiler doesn't optimize use of it but doesn't go so far as to bother with fences? But then the middle ground would be like expert mode, which isn't really what you want. Maybe we're good with just shared and unshared. Sean
Aug 01 2008
parent BCS <ao pathlink.com> writes:
Reply to Sean,

 Yeah, the idea of having a unifying label makes some sense, but I
 haven't been able to figure out what it would mean in terms of 
 behavior.

 Maybe we're good with just shared and unshared.

The only useful middle ground I see is covered by shared + const (one thread wright, many thread read with whatever else it takes to make that work)
Aug 01 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"superdan" wrote
 Steven Schveighoffer Wrote:
 I'm thinking more in the case of functions.  If I have a function foo, 
 and I
 want to pass my shared data version to it, I need to re-implement foo 
 with
 the parameters as being shared.  Imagine a function with several 
 parameters,
 in which you want to pass a combination of shared/unshared.  That's 2^n
 variations you have to write.

but the code there *is* different. there are fence combinations & shit. i guess in such cases you'd need a template.

The issue I see is that it's not as simple as flipping a switch. If I want to use an object as a shared object, it needs to implement that shared interface now. Might as well code a completely different object. And in that case, can't this just be a library solution (i.e. derive from this object if you want shared access)? You'd probably need to bring volatile back :)
 I think at the very least, for this to be palatable, there needs to be
 another modifier that unifies shared and unshared.  Similar to how const
 unifies mutable and invariant.

sounds interesting but i don't get it. we have: invariant == never changes const == i won't change it mutable == fuck you, i'm changing in the shared cases we have: unshared == never seen by 2 threads ? == ? shared == fuck you, i'm shared so how would that go. i won't share it? i won't write to it? (that's useless bc of read fences.) anyway this is intriguing shit. unification is power.

I have no idea what the middle ground is :) I'm just saying that without that middle ground, it's going to feel like I'm writing code specifically for sharing or not sharing, and the shared keyword loses a lot of its meaning as a general type modifier. I can't just slap a shared label on anything because that object needs to be specifically written to be a shared object. And in the case of functions which take those objects or data types as parameters, slapping a shared label on something means I have to use a completely different set of functions, which might not exist. If I have to use a library for some reason or another, I might just be tempted to cast away the shared. I might have no other choice. -Steve
Aug 01 2008
next sibling parent BCS <ao pathlink.com> writes:
Reply to Steven,

 I have no idea what the middle ground is :)  I'm just saying that
 without that middle ground, it's going to feel like I'm writing code
 specifically for sharing or not sharing,

I stand corrected the middle ground is "don't let me do anything where it matters" No cocreate thing would take on this attribute but references with it could be made from either side.
 and the shared keyword loses
 a lot of its meaning as a general type modifier.  I can't just slap a
 shared label on anything because that object needs to be specifically
 written to be a shared object.
 
 And in the case of functions which take those objects or data types as
 parameters, slapping a shared label on something means I have to use a
 completely different set of functions, which might not exist.  If I
 have to use a library for some reason or another, I might just be
 tempted to cast away the shared.  I might have no other choice.
 
 -Steve
 

Aug 01 2008
prev sibling parent JAnderson <ask me.com> writes:
Steven Schveighoffer wrote:
 "superdan" wrote
 Steven Schveighoffer Wrote:
 I'm thinking more in the case of functions.  If I have a function foo, 
 and I
 want to pass my shared data version to it, I need to re-implement foo 
 with
 the parameters as being shared.  Imagine a function with several 
 parameters,
 in which you want to pass a combination of shared/unshared.  That's 2^n
 variations you have to write.

guess in such cases you'd need a template.

The issue I see is that it's not as simple as flipping a switch. If I want to use an object as a shared object, it needs to implement that shared interface now. Might as well code a completely different object. And in that case, can't this just be a library solution (i.e. derive from this object if you want shared access)? You'd probably need to bring volatile back :)
 I think at the very least, for this to be palatable, there needs to be
 another modifier that unifies shared and unshared.  Similar to how const
 unifies mutable and invariant.

invariant == never changes const == i won't change it mutable == fuck you, i'm changing in the shared cases we have: unshared == never seen by 2 threads ? == ? shared == fuck you, i'm shared so how would that go. i won't share it? i won't write to it? (that's useless bc of read fences.) anyway this is intriguing shit. unification is power.

I have no idea what the middle ground is :) I'm just saying that without that middle ground, it's going to feel like I'm writing code specifically for sharing or not sharing, and the shared keyword loses a lot of its meaning as a general type modifier. I can't just slap a shared label on anything because that object needs to be specifically written to be a shared object. And in the case of functions which take those objects or data types as parameters, slapping a shared label on something means I have to use a completely different set of functions, which might not exist. If I have to use a library for some reason or another, I might just be tempted to cast away the shared. I might have no other choice. -Steve

Hopefully the shared data will be encapsulated such that you communicate with it though some lightweight class that converts the pieces that your sharing into something unshared functions can work with. We might then only need a small set of standard lib functions for shared memory which do mostly shared memory specific stuff. However we'll see how things go I guess. -Joel
Aug 02 2008
prev sibling next sibling parent reply superdan <super dan.org> writes:
Steven Schveighoffer Wrote:

 "Walter Bright" wrote
 Steven Schveighoffer wrote:
 "Walter Bright" wrote
 Nearly all global data is assumed to be and treated as if it were 
 unshared. So making unshared the default is the right solution. And 
 frankly, if you're using a lot of global variables, you might want to 
 reevaluate what you're doing. Lots of global variables is the 80's style 
 of programming :-)

Global means the world can see it, meaning that it's shared between all. Even VB.net uses 'Shared' as the keyword to mean 'global'

The idea is that encapsulation is better, and having something shared between everyone violates encapsulation. When you have a global variable 'int x' that everyone can read and write to, and there's a bug, you have the whole program to search for that bug. The principle of encapsulation is that each chunk of data is visible only to the code that needs to see it, and no more.

So if I write: shared int x; As a global variable, how does this help encapsulation? In the current model, if you need shared data, you use global variables. If you don't need shared data, use member or stack variables. My point is that what you will have done is just made the person who wants a global variable write 'shared' in front of it. I don't see how this helps him protect the variable at all. It just seems like you are enforcing something that already can be enforced.

i dun think so. first off it's naive to assume that global == shared. no way jose. almost all use of shared data is with heap allocated objects that several threads mess with. agreed there are good cases to share shit in a global. but that is the fringe case. not the usual case. second if you write shared int x then all loads/stores of x are fence protected. i might talk outta my ass but if i understand walt you can't just say y = x or x = 5. you must call some intrinsic shit, for example y = load(x) and store(x, 5). not sure i like that actually. third, the interesting shit starts when you take x's address. the shared quality of x goes with its type so &x is shared(int)*, not int*. i might again talk outta my ass but it looks like the compiler has info to fence all shit properly.
 (Programming languages started out with everything being global data, and 
 has moved away from that ever since.)

I'm not advocating using global variables over stack or member variables. All I'm saying is that this 'shared/unshared' model doesn't seem to me like it will eliminate the need for threading constructs, or even help with it.

here is where you apply my other message. what seems or not to you is zilch. come with facts. real arguments and shit.
 Yeah, because all us cowboys don't like your kind.  Maybe we need to get 
 us a rope and have a lynchin.  Seriously, how can you say that the 
 current threadding tools are 'uncontrolled' (i.e. wild west)?

Because of the common multithreaded bug http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html for one example. There is no threading tool I'm aware of that can prevent or detect such bugs.

As described on that page, the problem was fixed with JDK 5, and can be solved using the volatile modifier.

and if you forgot to put volatile your plan is fucked right there. i take issue with c++0x and java 5 equally. they suck shitty goat balls. they *allow* you to write correct code. same as the police allows you to climb mt everest. thank you very much assholes. they do nothing to actually help you with that shit. fuck that shit. if i understand d2 you can't have the dclp bug in d2 even if you tried. the way shit works is you can't have a global that's not shared. if it's shared then the compiler makes it fence protected. if it's fence protected you don't have the dclp bug. problem solved.
 I spend lots of time thinking about multithreadded issues, and make sure 
 my software works properly.  I think the level of quality for threadding 
 issues depends on the coder, not the tools.

I believe the tools can make it easier.

I do too. But I don't see this one being that tool.

see comment above.
 In the case of shared/unshared, it's not going to change anything, except 
 now I have to declare things I didn't have to declare before.  I.e. 
 having shared/unshared is going to be just as wild as before.

Why? First of all, unshared data isn't going to have sequential or sync issues, by definition. Already, you've cut the problem domain down by a huge chunk. Next, shared data access will come with fences or sync. That isn't going to guarantee no deadlocks, but it will guarantee sequential consistency, and at the very least will dramatically cut the problem domain down.

Are you saying that there will be an automatic notion by the compiler that implements the fences, or that I have to add them on top? If the former, then I don't remember reading that in the article, and that does sound promising.

i'm also curious. walt?
 Except now instead of the compiler helping you, you have pushed aside 
 that help and said 'I know what I'm doing'.  Oops, back to the wild west 
 :)

If you want the wild west, you have it, if you want compiler help instead, you got it. How is that worse than C++ or Java, where you always have the wild west and no help at all?

What I'm saying is that if you have to cast just to get something working, you have defeated the system. I'm not saying that you are back to the wild west *by choice*, I'm saying you will most likely end up having to do that just to get it to work. I'm thinking of many cases where you have to use old code, or old libraries that don't have this feature, or code written by someone unaware of the details.

i'd rather break old code than have the shitty model of today. and code written by someone unaware of threading details? you gotta be kidding. i'd erase that code in a second.
 True, but having it happen implicitly is even worse, because there's no 
 indication that it is happening.

dmd mycode.d Error: when calling foo(shared int *), cannot pass int * edit mycode.d, cast to shared int * OK, now it works :) Probably without any problems, because the compiler has no idea whether I'm going to change it in another thread. Hell, I might not even HAVE more than one thread! But the result is, we're back to the same model as before. And now I have to cast everything. Annoying.

Non-shared can be implicitly cast to shared, as that is always safe. Just not the other way.

How is that possible? shared int *x; void foo(shared int *y) { x = y; } int *x2; void bar() { foo(x2); } After calling bar, isn't x2 now both shared (as x) and unshared at the same time? I think you need casts for both ways.

looks like walt has a problem in his hands :))
 I think shared/unshared is analogous to mutable/invariant.  There is no 
 implicit cast.

looks the same to me too.
 Please let me decide whether I'm far better off.

Ok. D offers both - and for the guy maintaining your code, there'll at least be clear indications of where to look for the source of elusive threading bugs.

All I was saying with that comment is the notion that 'Walter knows best' is not a convincing argument.

"steven schveighoffer seems to feel differently" doesn't help either.
 Optlink currently has a threading bug in it. I have no idea where to look 
 for it in the source code.

Threading problems are very difficult to find. I don't think the shared/unshared model will help with that, especially since most likely you will have to break it to get things working.

what things would you need to break to get things working.
 I generally can only find multithreading issues with lots of logging, and 
 running through potentially offending code in my head.

and that disables d2's premise how.
 I think that this idea has potential, and could possibly lead to something 
 that is helpful.  The thinking is in the right direction.  But I'm not 
 convinced that this incarnation will be helpful.  I'd have to see examples 
 of how this would be useful to understand it better.
 
 And please PLEASE make it backwards compatible.  I don't see any reason why 
 it must be shared that is the tagged value.

i think you have a basic contradiction here. backward is shit. you just said it. to debug mt shit you need to log and rack your brains and shit. then without missing a beat you go you want to keep all that shit. shit man. if shared is only one iota better i'm all for breaking with the past. the past is a fucking world of pain. let's not forget that.
Aug 01 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from superdan (super dan.org)'s article
 Steven Schveighoffer Wrote:
 "Walter Bright" wrote
 Non-shared can be implicitly cast to shared, as that is always safe. Just
 not the other way.

How is that possible? shared int *x; void foo(shared int *y) { x = y; } int *x2; void bar() { foo(x2); } After calling bar, isn't x2 now both shared (as x) and unshared at the same time? I think you need casts for both ways.


That, or 'shared' applies only to the pointer, not to the value being pointed to. However, given the const system I'd be inclined to think that 'shared' may be transitive, in which case yeah, you've got a problem :-) Sean
Aug 01 2008
parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Sean Kelly (sean invisibleduck.org)'s article
 == Quote from superdan (super dan.org)'s article
 Steven Schveighoffer Wrote:
 "Walter Bright" wrote
 Non-shared can be implicitly cast to shared, as that is always safe. Just
 not the other way.

How is that possible? shared int *x; void foo(shared int *y) { x = y; } int *x2; void bar() { foo(x2); } After calling bar, isn't x2 now both shared (as x) and unshared at the same time? I think you need casts for both ways.


However, given the const system I'd be inclined to think that 'shared' may be transitive, in which case yeah, you've got a problem :-)

Err... I spoke too soon. Not a problem because then the value would have to be shared as well. I'd guess this is how it will work. Viral, just like const. Sean
Aug 01 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
superdan wrote:
 and if you forgot to put volatile your plan is fucked right there. i
 take issue with c++0x and java 5 equally. they suck shitty goat
 balls. they *allow* you to write correct code. same as the police
 allows you to climb mt everest.

I think you put your finger on the problem. The default behavior of C++ and Java is to do the wrong thing. You have to do extra work to do the right thing. D tries to reverse that by making the default the correct thing, and you have to work extra to screw it up.
 Are you saying that there will be an automatic notion by the
 compiler that implements the fences,


Yes.
Aug 01 2008
prev sibling parent Dee Girl <deegirl noreply.com> writes:
Steven Schveighoffer Wrote:

 shared int *x;
 
 void foo(shared int *y)
 {
     x = y;
 }
 
 int *x2;
 
 void bar()
 {
     foo(x2);
 }
 
 After calling bar, isn't x2 now both shared (as x) and unshared at the same 
 time?  I think you need casts for both ways.
 
 I think shared/unshared is analogous to mutable/invariant.  There is no 
 implicit cast.

Agree with Steve. There should not be easy casting of pointers. i think cast from not shared int to shared int is good. but int* to shared int* is not good. exactly like with invariant. The new model is very interesting! Good Walter I hoped you have a clever solution like invariant and it looks that you have ^_^. Thank you, Dee Girl
Aug 01 2008
prev sibling next sibling parent reply JAnderson <ask me.com> writes:
Steven Schveighoffer wrote:
<Snip>
 dmd mycode.d
 Error: when calling foo(shared int *), cannot pass int *

 edit mycode.d, cast to shared int *

 OK, now it works :)   Probably without any problems, because the 

Hell, I might not even HAVE more than one thread!
 But the result is, we're back to the same model as before.  And now I 

<Snip> The idea behind compile-time checking like this is that you can quickly identify errors. If someone writes something in a lib you use that is not share safe, you'll know right of the bat. What you want to do with encapsulation is isolate problems at the point at which it occurs, not 5 or 10 classes/functions away when the side effect finally causes weird behavior. With a shared policy you'd be able to encapsulate all shared data to just the parts of the program that use it. That way you have only small set of places to figure out what went wrong. Furthermore it provides a consistent documentation about how a particular object can be used. For example if someone suddenly decides that one of their functions can only work with sharable memory now and your using a non-shared object with it, the compiler will out you when you upgrade that new api and try to compile. If you can't create a shared object or invariant to pass to that function then you dam well better know what your doing. -Joel
Jul 31 2008
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"JAnderson" wrote
 Steven Schveighoffer wrote:
 <Snip>
 dmd mycode.d
 Error: when calling foo(shared int *), cannot pass int *

 edit mycode.d, cast to shared int *

 OK, now it works :)   Probably without any problems, because the

Hell, I might not even HAVE more than one thread!
 But the result is, we're back to the same model as before.  And now I

<Snip> The idea behind compile-time checking like this is that you can quickly identify errors. If someone writes something in a lib you use that is not share safe, you'll know right of the bat.

I believe the direction that this is heading is promising, but my concern is that it actually won't be helpful as currently described. Because I don't think you can implicitly cast shared to unshared and vice versa, you will need to populate your code with casts wherever you cross the boundaries. If this is a lot, then you will end up creating too much noise to be able to find the problems. This model seems equivalent to having mutable and invariant, but not const (the link between). -Steve
Aug 01 2008
prev sibling parent reply superdan <super dan.org> writes:
Steven Schveighoffer Wrote:

 "Walter Bright" wrote
 Steven Schveighoffer wrote:
 "Walter Bright" wrote
 http://www.reddit.com/comments/6u7k0/sharing_in_d/

There are 2 problems I see with this scheme. First, that the default is 'unshared'. This is going to break a lot of existing code, and make peoples lives miserable who do not want to deal with unshared non-stack data.

Nearly all global data is assumed to be and treated as if it were unshared. So making unshared the default is the right solution. And frankly, if you're using a lot of global variables, you might want to reevaluate what you're doing. Lots of global variables is the 80's style of programming :-)

I have no idea where you came up with this. To me global means shared. Global means the world can see it, meaning that it's shared between all. Even VB.net uses 'Shared' as the keyword to mean 'global'
 I would hazard to guess that adopting this would cause a larger rift than 
 const.

Perhaps. But the alternative is the current wild west approach to multithreaded programming. With the proliferation of multicore computers, the era where this is acceptable is coming to an end.

Yeah, because all us cowboys don't like your kind. Maybe we need to get us a rope and have a lynchin. Seriously, how can you say that the current threadding tools are 'uncontrolled' (i.e. wild west)? I spend lots of time thinking about multithreadded issues, and make sure my software works properly. I think the level of quality for threadding issues depends on the coder, not the tools. In the case of shared/unshared, it's not going to change anything, except now I have to declare things I didn't have to declare before. I.e. having shared/unshared is going to be just as wild as before. I may be wrong, and this shared/unshared thing will be really great for people. But I think it needs a lot of work before it's helpful. In its current incarnation, I'll call it the 'shared wild west' approach :P
 Second, the fact that you can't implicitly cast shared to unshared and 
 vice versa.  It's going to make communication between both 'worlds' very 
 error prone, as you will be required to cast for any call from one to the 
 other.

I think the reverse is true. Moving data between those worlds is dangerous and needs to be carefully vetted, so requiring an explicit cast will reduce the chance of this happening unintentionally.

Except now instead of the compiler helping you, you have pushed aside that help and said 'I know what I'm doing'. Oops, back to the wild west :)
 People will do this just to get their code to work, without thinking 
 about the consequences.

True, but having it happen implicitly is even worse, because there's no indication that it is happening.

dmd mycode.d Error: when calling foo(shared int *), cannot pass int * edit mycode.d, cast to shared int * OK, now it works :) Probably without any problems, because the compiler has no idea whether I'm going to change it in another thread. Hell, I might not even HAVE more than one thread! But the result is, we're back to the same model as before. And now I have to cast everything. Annoying.
 Even those that do think about the consequences, can't have the compiler 
 statically check the cast in either direction, so once you cast, you lose 
 all the benefit.

But still, you're far better off than the current wild west approach where everything is implicitly shared with no protection whatsoever. The popular double checked locking bug will be impossible to code in D without stuffing in explicit casts. The casts will be a red flag that the programmer is making a mistake.

Please let me decide whether I'm far better off. I don't need protection from stuff that doesn't matter. I will still have to lock shared data, and still have to cast to get things to work, so I'm not better off. You can't tell me otherwise, because all this stuff is a figment of your imagination. You have no proof. Until you can show me that I'm better off with an actual example, then I believe we both are equally right :) -Steve

you may as well be equally right. or even more right, as you usually are. sure you are a great hacker who knows threads in and out, as "you spend a lot of time thinking about multithreaded issues". i'm impressed. i do suggest you run a lil experiment one day tho. google for walter bright. figure out what kinds of shit he's done. google for bartosz milewski. figure out for what kinds of shit he's done. google for andrei alexanderescu. figure out for what kinds of shit he's done. then google for steven schveighoffer. unless sure enough you are hans boehm in disguise. then ask yourself. "is my big mouth going to make up for all this?"
Jul 31 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"superdan" wrote
 you may as well be equally right. or even more right, as you usually are. 
 sure you are a great hacker who knows threads in and out, as "you spend a 
 lot of time thinking about multithreaded issues". i'm impressed. i do 
 suggest you run a lil experiment one day tho. google for walter bright. 
 figure out what kinds of shit he's done. google for bartosz milewski. 
 figure out for what kinds of shit he's done. google for andrei 
 alexanderescu. figure out for what kinds of shit he's done. then google 
 for steven schveighoffer. unless sure enough you are hans boehm in 
 disguise. then ask yourself. "is my big mouth going to make up for all 
 this?"

Just because I'm not published all over google doesn't mean I don't know anything. Your artistic use of the english language combined with bullying tactics doesn't really phase me, as I care nothing about ego. So go right ahead and bitch about what I don't know :) Last I heard, this is a public forum, and I'm free to question Walter and his team as much as I want. I can't believe you pulled the "do you know who I am" card for Walter :) What do I get if I google for superdan? http://www.youtube.com/watch?v=uLLk42PcM9I -Steve
Aug 01 2008
parent reply superdan <super dan.org> writes:
Steven Schveighoffer Wrote:

 "superdan" wrote
 you may as well be equally right. or even more right, as you usually are. 
 sure you are a great hacker who knows threads in and out, as "you spend a 
 lot of time thinking about multithreaded issues". i'm impressed. i do 
 suggest you run a lil experiment one day tho. google for walter bright. 
 figure out what kinds of shit he's done. google for bartosz milewski. 
 figure out for what kinds of shit he's done. google for andrei 
 alexanderescu. figure out for what kinds of shit he's done. then google 
 for steven schveighoffer. unless sure enough you are hans boehm in 
 disguise. then ask yourself. "is my big mouth going to make up for all 
 this?"

Just because I'm not published all over google doesn't mean I don't know anything. Your artistic use of the english language combined with bullying tactics doesn't really phase me, as I care nothing about ego. So go right ahead and bitch about what I don't know :) Last I heard, this is a public forum, and I'm free to question Walter and his team as much as I want. I can't believe you pulled the "do you know who I am" card for Walter :)

thanks for keeping ur cool. really appreciate that. my intent was not to bully you and shit. this is programming. it's not entomology. anybody who's somebody in programming *is* on the web somewhere for the web is nerdworld. some participation to an open source project. some blog. some article they've written. that's what i see all around. but i still agree. sometimes you can know your shit without being published. you work for nasa, cia, or some secretive hedge fund. or you just don't like sharing shit. no problem. but without a track record you must come with real good *factual* shit to be credible. not "i spend a lot of time thinking about this shit". not what you believe. without a proven track record nobody gives a shit on how you spend your nights or on what you believe. so as long as you stick to facts u should be in good shape. if you come with "my opinion is" shit then you should understand nobody will give a shit. in fact they will give a negative shit because that further fucks your credibility. as an example of good factual shit is your point that nonshared -> shared should not be implicit. now you're talking. i'll think about that shit too. insofar as this being a public forum. i'm a prime abuser of that with my shitfucking and shit. but that is nothing compared to the technical abuse this forum has seen and still does. if that goes down i'd be happy to get my shitfucking shit down too.
 What do I get if I google for superdan?
 
 http://www.youtube.com/watch?v=uLLk42PcM9I
 
 -Steve 

sweet :)
Aug 01 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"superdan" wrote
 Steven Schveighoffer Wrote:

 "superdan" wrote
 you may as well be equally right. or even more right, as you usually 
 are.
 sure you are a great hacker who knows threads in and out, as "you spend 
 a
 lot of time thinking about multithreaded issues". i'm impressed. i do
 suggest you run a lil experiment one day tho. google for walter bright.
 figure out what kinds of shit he's done. google for bartosz milewski.
 figure out for what kinds of shit he's done. google for andrei
 alexanderescu. figure out for what kinds of shit he's done. then google
 for steven schveighoffer. unless sure enough you are hans boehm in
 disguise. then ask yourself. "is my big mouth going to make up for all
 this?"

Just because I'm not published all over google doesn't mean I don't know anything. Your artistic use of the english language combined with bullying tactics doesn't really phase me, as I care nothing about ego. So go right ahead and bitch about what I don't know :) Last I heard, this is a public forum, and I'm free to question Walter and his team as much as I want. I can't believe you pulled the "do you know who I am" card for Walter :)

thanks for keeping ur cool. really appreciate that. my intent was not to bully you and shit. this is programming. it's not entomology. anybody who's somebody in programming *is* on the web somewhere for the web is nerdworld. some participation to an open source project. some blog. some article they've written. that's what i see all around.

I probably have more hits under schveiguy than Steven Schveighoffer. But I don't really write articles. I wrote one for topcoder when I was into that (about threading coincidentally).
 but i still agree. sometimes you can know your shit without being 
 published. you work for nasa, cia, or some secretive hedge fund. or you 
 just don't like sharing shit. no problem. but without a track record you 
 must come with real good *factual* shit to be credible. not "i spend a lot 
 of time thinking about this shit". not what you believe. without a proven 
 track record nobody gives a shit on how you spend your nights or on what 
 you believe.

What I meant by that is, I think possibly the only solution for multithreadded issues is careful planning, training, and experience. In otherwords, my threading code works because I pay careful attention to the threading details. It might be impossible for a technical solution to exist to prevent Joe Newb programmer from making threading mistakes.
 so as long as you stick to facts u should be in good shape. if you come 
 with "my opinion is" shit then you should understand nobody will give a 
 shit. in fact they will give a negative shit because that further fucks 
 your credibility.

You don't have to believe me. Nobody has to believe me. The fact that I stated my opinion is good enough for me. If I turn out to be right, then people might listen to me next time. If I turn out to be wrong, then it still won't stop me from stating my opinion on the next issue. Mind, I can't say anything about facts because I don't have any. I'm very careful to state things in terms of what "I think", and "my opinion". I don't have any more facts than Walter and company to know whether this concept will be useful. All I can say is what I think might happen (as is all Walter can say too). If it turns out to be the best thing since transitive const, then I'm all for it. Remember that Walter and company had several iterations before they got that right. I think that will probably be the case here too.
 insofar as this being a public forum. i'm a prime abuser of that with my 
 shitfucking and shit. but that is nothing compared to the technical abuse 
 this

shitfucking shit down too. I don't know what 'shitfucking' is, but it sounds very unpleasant :) -Steve
Aug 01 2008
parent reply superdan <super dan.org> writes:
Steven Schveighoffer Wrote:

 "superdan" wrote
 Steven Schveighoffer Wrote:

 "superdan" wrote
 you may as well be equally right. or even more right, as you usually 
 are.
 sure you are a great hacker who knows threads in and out, as "you spend 
 a
 lot of time thinking about multithreaded issues". i'm impressed. i do
 suggest you run a lil experiment one day tho. google for walter bright.
 figure out what kinds of shit he's done. google for bartosz milewski.
 figure out for what kinds of shit he's done. google for andrei
 alexanderescu. figure out for what kinds of shit he's done. then google
 for steven schveighoffer. unless sure enough you are hans boehm in
 disguise. then ask yourself. "is my big mouth going to make up for all
 this?"

Just because I'm not published all over google doesn't mean I don't know anything. Your artistic use of the english language combined with bullying tactics doesn't really phase me, as I care nothing about ego. So go right ahead and bitch about what I don't know :) Last I heard, this is a public forum, and I'm free to question Walter and his team as much as I want. I can't believe you pulled the "do you know who I am" card for Walter :)

thanks for keeping ur cool. really appreciate that. my intent was not to bully you and shit. this is programming. it's not entomology. anybody who's somebody in programming *is* on the web somewhere for the web is nerdworld. some participation to an open source project. some blog. some article they've written. that's what i see all around.

I probably have more hits under schveiguy than Steven Schveighoffer. But I don't really write articles. I wrote one for topcoder when I was into that (about threading coincidentally).

now yer talking. keep on doing that.
 but i still agree. sometimes you can know your shit without being 
 published. you work for nasa, cia, or some secretive hedge fund. or you 
 just don't like sharing shit. no problem. but without a track record you 
 must come with real good *factual* shit to be credible. not "i spend a lot 
 of time thinking about this shit". not what you believe. without a proven 
 track record nobody gives a shit on how you spend your nights or on what 
 you believe.

What I meant by that is, I think possibly the only solution for multithreadded issues is careful planning, training, and experience. In otherwords, my threading code works because I pay careful attention to the threading details. It might be impossible for a technical solution to exist to prevent Joe Newb programmer from making threading mistakes.

and you're implying that it can't be done any better. you know, if everybody thought like you there'd be no progress. i read napoleon's biography a while ago. one smart motherfucker that was. he really could do two things at the same time. i could only go as far as chew gum and fart. anyway there was this general of his. forgot his name. call him general mofo. so at austerlitz napoleon says let's do this and that. mofo comes back: "if i were you i'd do this and that". napoleon says: "that's why you are mofo and i'm fucking napoleon". i might've added a word in the quote somewhere :) i was working at intel. there's this layout program that would take forfuckingever on a design i'd given it. so during lunch i'm like, "what a fucking piece of shit this layout algo is." and a new coworker smiles and says "i know. i designed it." he was kind enough to explain what problems he'd overcome. like heuristics on np complete shit. i don't even know exactly what that is. sure enough, when it's done his program did a layout i couldn't imagine in a brazillion years. these guys operate at a different level. and as far as walter or bartosz are concerned i'm a pathetic loser. at least i'm glad when i can appreciate a good idea if i see it. and the more it goes about how i feel it can't be done, the better the idea. at least with time i learned not to come all cocky and shit with stuff i don't grok.
 so as long as you stick to facts u should be in good shape. if you come 
 with "my opinion is" shit then you should understand nobody will give a 
 shit. in fact they will give a negative shit because that further fucks 
 your credibility.

You don't have to believe me. Nobody has to believe me. The fact that I stated my opinion is good enough for me. If I turn out to be right, then people might listen to me next time. If I turn out to be wrong, then it still won't stop me from stating my opinion on the next issue.

doesn't work that way dewd. it's like crying wolf whenever you feel it in your urine. open the cabbage patches. then the mind. then the piehole. that's how it works. i read this thread stuff yesterday a few times. my first reaction was it's useless. second reaction was it's restrictive as shit. third read i thought they might be up to something. and it was the interaction with invariant that brought it all home for me. most importantly i didn't shout my piehole around after the first read.
  Mind, I 
 can't say anything about facts because I don't have any.  I'm very careful 
 to state things in terms of what "I think", and "my opinion".  I don't have 
 any more facts than Walter and company to know whether this concept will be 
 useful.  All I can say is what I think might happen (as is all Walter can 
 say too).  If it turns out to be the best thing since transitive const, then 
 I'm all for it.  Remember that Walter and company had several iterations 
 before they got that right.  I think that will probably be the case here 
 too.

my point is you (and me too) have less facts, less experience, less smarts, and less intuition than walt & co. if we tell them about a mistake, fine. but if we go with "i feel shit" that's not progress. it's good you compare with the const shit. that's the most fucking awesome thing about d2. if you asked me before i would've told you nobody can pull that shit and live. more over. walt has got a shitstorm the size of fucking china when he got it wrong. if i were walt i would've given up. but that's why walt is walt he kept at it and pushed the shit through. what pisses me off is that to this day people still bitch about const while refusing to actually understand it. it's not even hard. first understand. then bitch.
Aug 01 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
superdan wrote:
 i read napoleon's biography a while ago. one smart motherfucker that
 was. he really could do two things at the same time. i could only go
 as far as chew gum and fart. anyway there was this general of his.
 forgot his name. call him general mofo. so at austerlitz napoleon
 says let's do this and that. mofo comes back: "if i were you i'd do
 this and that". napoleon says: "that's why you are mofo and i'm
 fucking napoleon". i might've added a word in the quote somewhere :)

Do you believe that General McAuliffe really said "nuts" at the Battle of the Bulge? I don't. <g> http://en.wikipedia.org/wiki/Anthony_McAuliffe#.22Nuts.22
Aug 01 2008
parent reply superdan <super dan.org> writes:
Walter Bright Wrote:

 superdan wrote:
 i read napoleon's biography a while ago. one smart motherfucker that
 was. he really could do two things at the same time. i could only go
 as far as chew gum and fart. anyway there was this general of his.
 forgot his name. call him general mofo. so at austerlitz napoleon
 says let's do this and that. mofo comes back: "if i were you i'd do
 this and that". napoleon says: "that's why you are mofo and i'm
 fucking napoleon". i might've added a word in the quote somewhere :)

Do you believe that General McAuliffe really said "nuts" at the Battle of the Bulge? I don't. <g> http://en.wikipedia.org/wiki/Anthony_McAuliffe#.22Nuts.22

let's see. four-words expletive too strong for the american public. sure it was "poop" :) can't think of bastogne without thinking of BoB. what an awesome movie that is.
Aug 01 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
superdan wrote:
 Do you believe that General McAuliffe really said "nuts" at the Battle 
 of the Bulge? I don't. <g> 
 http://en.wikipedia.org/wiki/Anthony_McAuliffe#.22Nuts.22

let's see. four-words expletive too strong for the american public. sure it was "poop" :) can't think of bastogne without thinking of BoB. what an awesome movie that is.

My father met the man and asked him. The actual word rhymes with "spit". I'm amused by the people who think a GI would really use the word "nuts".
Aug 01 2008
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"superdan" wrote
 Steven Schveighoffer Wrote:

 "superdan" wrote
 but i still agree. sometimes you can know your shit without being
 published. you work for nasa, cia, or some secretive hedge fund. or you
 just don't like sharing shit. no problem. but without a track record 
 you
 must come with real good *factual* shit to be credible. not "i spend a 
 lot
 of time thinking about this shit". not what you believe. without a 
 proven
 track record nobody gives a shit on how you spend your nights or on 
 what
 you believe.

What I meant by that is, I think possibly the only solution for multithreadded issues is careful planning, training, and experience. In otherwords, my threading code works because I pay careful attention to the threading details. It might be impossible for a technical solution to exist to prevent Joe Newb programmer from making threading mistakes.

and you're implying that it can't be done any better. you know, if everybody thought like you there'd be no progress.

I'm not saying that we shouldn't try. I'm just saying it *might* be impossible. I encourage Walter to solve it, but I can't see how this solution does it. Look into NP-complete. It's a set of problems that nobody can write a program to solve it (efficiently anyways). First one I ever heard of is the traveling salesman problem: http://en.wikipedia.org/wiki/Traveling_salesman_problem
 so as long as you stick to facts u should be in good shape. if you come
 with "my opinion is" shit then you should understand nobody will give a
 shit. in fact they will give a negative shit because that further fucks
 your credibility.

You don't have to believe me. Nobody has to believe me. The fact that I stated my opinion is good enough for me. If I turn out to be right, then people might listen to me next time. If I turn out to be wrong, then it still won't stop me from stating my opinion on the next issue.

doesn't work that way dewd. it's like crying wolf whenever you feel it in your urine. open the cabbage patches. then the mind. then the piehole. that's how it works. i read this thread stuff yesterday a few times. my first reaction was it's useless. second reaction was it's restrictive as shit. third read i thought they might be up to something. and it was the interaction with invariant that brought it all home for me. most importantly i didn't shout my piehole around after the first read.

I admit that I already knew this shared/unshared was coming :) So I already had thought about it over a month ago, but I wasn't allowed to talk about it on the NG. But I'm a little disappointed that it's no different than the version I saw before... Bottom line, I did think about it before posting. Quite a bit.
  Mind, I
 can't say anything about facts because I don't have any.  I'm very 
 careful
 to state things in terms of what "I think", and "my opinion".  I don't 
 have
 any more facts than Walter and company to know whether this concept will 
 be
 useful.  All I can say is what I think might happen (as is all Walter can
 say too).  If it turns out to be the best thing since transitive const, 
 then
 I'm all for it.  Remember that Walter and company had several iterations
 before they got that right.  I think that will probably be the case here
 too.

my point is you (and me too) have less facts, less experience, less smarts, and less intuition than walt & co. if we tell them about a mistake, fine. but if we go with "i feel shit" that's not progress.

Hey, don't listen to me. Nobody has to do what I say based on a feeling. But I'm sure as hell not going to accept that if Walter feels good about it, it must be right, any more than you won't accept what I say because I don't feel good about it. I need proof. And the burden of proof is on Walter. I've already written multithreadded programs with the current D system, and they work. You need to convince me that this new way will work more than just "Trust me, you'll be better off".
 it's good you compare with the const shit. that's the most fucking awesome 
 thing about d2. if you asked me before i would've told you nobody can pull 
 that shit and live. more over. walt has got a shitstorm the size of 
 fucking china when he got it wrong. if i were walt i would've given up. 
 but that's why walt is walt he kept at it and pushed the shit through. 
 what pisses me off is that to this day people still bitch about const 
 while refusing to actually understand it. it's not even hard. first 
 understand. then bitch.

I am one of those that fully understands the const system, and I still think it is missing some pieces :) Every proposal I've made to fill in those pieces on the NG and to Andrei directly ultimately results in a response like "yes that looks like a sound idea, and would work, but we *feel* that it would make people like const less, so we're not going to implement it." I love a lot of what Walter and Andrei have done, but when ideas are shot down due to a perception of what might happen in the future, it seems to be based a lot less on fact than I would like. -Steve
Aug 01 2008
prev sibling next sibling parent reply JAnderson <ask me.com> writes:
Steven Schveighoffer wrote:
 "Walter Bright" wrote
 http://www.reddit.com/comments/6u7k0/sharing_in_d/

There are 2 problems I see with this scheme. First, that the default is 'unshared'. This is going to break a lot of existing code, and make peoples lives miserable who do not want to deal with unshared non-stack data. I would hazard to guess that adopting this would cause a larger rift than const.

<Snip> As far as radical changes to the language breaking existing code, if Walter maintained that approach D would never beable to make radical and correct improvements (rather then half-work rounds). We would end up with C++. This is why we have D 1 and 2. D 2 is still the experimental branch. Yes it makes radical changes however D might never be able to provide better multi-threading support if it can't make breaking changes. My option is that the experimental branch of D should be correct first and backwoods compatible second. Having said that. I don't think this shared approach should be added to the language until const is sorted because that should provide a kinda proof of concept for the syntactics of shared memory. <Snip>
 
 -Steve 
 
 

Jul 31 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"JAnderson" wrote
 Steven Schveighoffer wrote:
 "Walter Bright" wrote
 http://www.reddit.com/comments/6u7k0/sharing_in_d/

There are 2 problems I see with this scheme. First, that the default is 'unshared'. This is going to break a lot of existing code, and make peoples lives miserable who do not want to deal with unshared non-stack data. I would hazard to guess that adopting this would cause a larger rift than const.

<Snip> As far as radical changes to the language breaking existing code, if Walter maintained that approach D would never beable to make radical and correct improvements (rather then half-work rounds). We would end up with C++. This is why we have D 1 and 2. D 2 is still the experimental branch. Yes it makes radical changes however D might never be able to provide better multi-threading support if it can't make breaking changes.

So should people wait to write libraries until all this is fleshed out? I mean, there is already a pretty significant code base that assumes shared is the default. When this ever gets around to being implemented (and released), how much work will it be to rewrite all code to either use a new model, or put a shared tag on every variable? It seems to me the logical approach is to assume shared and tag things as unshared.
 My option is that the experimental branch of D should be correct first and 
 backwoods compatible second.

That is a great recipe for the forking of D :) I'm not saying that breaking changes should be unacceptable, I'm just saying that there better be a really compelling reason to break things. I believe Walter's view of "wild west" programming is completely off target. Many good multithreadded applications exist today, without the aid of this shared/unshared view. I don't see how having this is going to magically solve any threadding issues. If anything it's going to just pop up as an annoying obstacle that is frequently bypassed with casts, making the system useless anyways. I don't know if this can be shown until the idea moves from theory to practice, so maybe we'll just have to wait and see. This could be a stepping stone to a really great system, just like the first const incarnations were awful, but the one we have now (save a few missing pieces) is pretty good. Just my opinion. -Steve
Jul 31 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Steven Schveighoffer (schveiguy yahoo.com)'s article
 "JAnderson" wrote
 My option is that the experimental branch of D should be correct first and
 backwoods compatible second.

changes should be unacceptable, I'm just saying that there better be a really compelling reason to break things.

libd forked the language and is far better for it. Tango has avoided this route because our primary goal is to provide a library for D. This seems to have turned out to be "provide a library for D 1.0" however, given the lack of support for certain programming methodologies in D 2.0 that Tango uses pervasively, as you're no doubt aware :-) This leaves Tango in a bit of a pickle, since it means either changing Tango or forking D if we ever want to move past D 1.0.
 I believe Walter's view of "wild west" programming is completely off target.
 Many good multithreadded applications exist today, without the aid of this
 shared/unshared view.  I don't see how having this is going to magically
 solve any threadding issues.  If anything it's going to just pop up as an
 annoying obstacle that is frequently bypassed with casts, making the system
 useless anyways.  I don't know if this can be shown until the idea moves
 from theory to practice, so maybe we'll just have to wait and see.  This
 could be a stepping stone to a really great system, just like the first
 const incarnations were awful, but the one we have now (save a few missing
 pieces) is pretty good.

Systems programming is the low-down dirtiest part of the Wild West, too. It's a realm where programmers do all sorts of things that a general applications programmer would be canned for, because it's necessary and because they *do* know what they're doing. I am very much concerned that the "future of D" is as a general applications language and that its systems language roots will be left to rot. And who needs another applications language, anyway? The world has a million of them. Sean
Jul 31 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Sean Kelly:
 I am very much concerned that the "future of D" is
 as a general applications language and that its systems language roots will
 be left to rot.  And who needs another applications language, anyway?  The
 world has a million of them.

I think D is already partially unfit for being a system language, the runtime memory footprint is large; here it's compared with Free Pascal: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=dlang&lang2=fpascal The GC can be disabled, but you have to carry it around in the executable anyway. The size of the executables produced by DMD is large compared to the exes you obtain from stripped C. At the moment you can't run such things on sytems with little RAM, as you can do with C. Regarding the hard real time systems, I think people there are scared of a GC (even if in practice it's not a problem). So at the moment there are many things you can do with C that are a problem to do with D. Bye, bearophile
Jul 31 2008
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article
 Sean Kelly:
 I am very much concerned that the "future of D" is
 as a general applications language and that its systems language roots will
 be left to rot.  And who needs another applications language, anyway?  The
 world has a million of them.


 http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=dlang&lang2=fpascal

Agreed. This is largely related to the generated TypeInfo, and is somewhat annoying.
 The GC can be disabled, but you have to carry it around in the executable
anyway. The size of the executables

on sytems with little RAM, as you can do with C. It's actually possible to create a D application that doesn't have a GC at all. Tango even supports this out of the box. The downside is that some language features rely on the existence of a GC and won't work properly without one. AAs are one example, and string concatenation is another. However, a sufficiently diligent programmer could just not use these features, or the runtime could be modified to explicitly support a GC-less application by making different assumptions about what happens to discarded memory, etc.
 Regarding the hard real time systems, I think people there are scared of a GC
(even if in practice it's not a problem).

There are soft real-time GCs. In fact, I believe there are hard real-time GCs as well--the Metronome project at IBM springs to mind. I would love to see such a GC for D, but I don't have the time and am also not certain that it's possible to make a hard real-time conservative GC (which D currently requires). I would be inclined to think that such a GC would be incremental and thus require more comprehensive type info, but I haven't given the topic enough thought to be certain about that. All that said, I believe it's entirely possible to write performance-critical code in D so long as the programmer is careful about memory allocation. And as Walter has said before, because even malloc is not time-constrained the same goes for any use of dynamic memory--GCs just magnify the issue. Server apps in Tango, for example, don't allocate any memory at all once initialization is complete. This is why they tend to be so blisteringly fast. It's also why Tango is designed the way it is--not always super-convenient for run of the mill apps programming, but quite scalable for high-end work. By contrast, I'd argue that Phobos is the opposite. Sean
Jul 31 2008
next sibling parent reply superdan <super dan.org> writes:
Sean Kelly Wrote:

 All that said, I believe it's entirely possible to write performance-critical
code in D so long as the
 programmer is careful about memory allocation.  And as Walter has said before,
because even
 malloc is not time-constrained the same goes for any use of dynamic
memory--GCs just magnify
 the issue.  Server apps in Tango, for example, don't allocate any memory at
all once initialization
 is complete.  This is why they tend to be so blisteringly fast.  It's also why
Tango is designed the
 way it is--not always super-convenient for run of the mill apps programming,
but quite scalable
 for high-end work.  By contrast, I'd argue that Phobos is the opposite.

i agree. std.algorithm i sleep with under my pillow. but std.xml. what a sick piece of shit that is. if they tried to make it slow on purpose they couldn't have succeeded better. std.xml must go.
Jul 31 2008
parent reply downs <default_357-line yahoo.de> writes:
superdan wrote:
 Sean Kelly Wrote:
 
 All that said, I believe it's entirely possible to write performance-critical
code in D so long as the
 programmer is careful about memory allocation.  And as Walter has said before,
because even
 malloc is not time-constrained the same goes for any use of dynamic
memory--GCs just magnify
 the issue.  Server apps in Tango, for example, don't allocate any memory at
all once initialization
 is complete.  This is why they tend to be so blisteringly fast.  It's also why
Tango is designed the
 way it is--not always super-convenient for run of the mill apps programming,
but quite scalable
 for high-end work.  By contrast, I'd argue that Phobos is the opposite.

i agree. std.algorithm i sleep with under my pillow. but std.xml. what a sick piece of shit that is. if they tried to make it slow on purpose they couldn't have succeeded better. std.xml must go.

Heh. Want to have some fun, take a look at std.zip. Then realize that, unless you unpack every member every time, the members you didn't unpack will still have their compressed data overwritten by a compressed version of the expanded data (which is ""). Then weep. --downs, immensely glad the zip archive he noticed this on was backed up in SVN.
Aug 01 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
downs wrote:
 Heh. Want to have some fun, take a look at std.zip.
 
 Then realize that, unless you unpack every member every time, the
 members you didn't unpack will still have their compressed data
 overwritten by a compressed version of the expanded data (which is
 "").
 
 Then weep.
 
 --downs, immensely glad the zip archive he noticed this on was backed
 up in SVN.

Please file this with bugzilla, or even better, a patch!
Aug 01 2008
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Sean Kelly:
 All that said, I believe it's entirely possible to write performance-critical
code in D so long as the
 programmer is careful about memory allocation.

I agree, in many D programs I have found that avoiding memory allocations can speed up the code 5-15 times. You can see the last time I have seen that in this thread: http://groups.google.com/group/comp.lang.python/browse_thread/thread/e291275df01756c6# But Java HotSpot shows that a good GC can make fast enough many programs that allocate memory often (but they often need 4-10 times more RAM). Bye, bearophile
Jul 31 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 All that said, I believe it's entirely possible to write performance-critical
code in D so long as the
 programmer is careful about memory allocation.  And as Walter has said before,
because even
 malloc is not time-constrained the same goes for any use of dynamic
memory--GCs just magnify
 the issue.  Server apps in Tango, for example, don't allocate any memory at
all once initialization
 is complete.  This is why they tend to be so blisteringly fast.  It's also why
Tango is designed the
 way it is--not always super-convenient for run of the mill apps programming,
but quite scalable
 for high-end work.  By contrast, I'd argue that Phobos is the opposite.

I wrote a version of Empire (the game) in D that does no allocation at all. Therefore, the gc never runs and there is never any unbounded delay. The gc is never going to pop up out of nowhere and sink your application. A gc only happens when you request memory from the gc. For the real time constrained section of code, the idea is to pre-allocate all the data you'll need first, then do no allocation within the critical section. In fact, such critical code in C++ does this anyway because there are no bounded time constraints on C++ new either. C malloc has no bound constraints, either.
Jul 31 2008
parent reply JAnderson <ask me.com> writes:
Walter Bright wrote:
 Sean Kelly wrote:
 All that said, I believe it's entirely possible to write 
 performance-critical code in D so long as the
 programmer is careful about memory allocation.  And as Walter has said 
 before, because even
 malloc is not time-constrained the same goes for any use of dynamic 
 memory--GCs just magnify
 the issue.  Server apps in Tango, for example, don't allocate any 
 memory at all once initialization
 is complete.  This is why they tend to be so blisteringly fast.  It's 
 also why Tango is designed the
 way it is--not always super-convenient for run of the mill apps 
 programming, but quite scalable
 for high-end work.  By contrast, I'd argue that Phobos is the opposite.

I wrote a version of Empire (the game) in D that does no allocation at all. Therefore, the gc never runs and there is never any unbounded delay. The gc is never going to pop up out of nowhere and sink your application. A gc only happens when you request memory from the gc. For the real time constrained section of code, the idea is to pre-allocate all the data you'll need first, then do no allocation within the critical section. In fact, such critical code in C++ does this anyway because there are no bounded time constraints on C++ new either. C malloc has no bound constraints, either.

This is true, new in C++ can seriously degrade performance if not manage properly. However calling a couple of 100 smallish news in C++ per frame is quite acceptable and has a infindecimal affect on performance, when working on windows. D however is another kettle of fish. You can't have any allocations during the active part of the game. You have to do it all a load points. Why? Because at some point the memory allocator will runout of free memory and then it will need to clear anything that's unused. Normally this wouldn't be a problem however it takes over a frame to flush; and that leads to a very noticeable stutter. Now I haven't tried realtime programming with allocations in the realtime part for a while so things might have changed however that's how it was the last time I was playing around with that stuff. Also I haven't tried Tangos. Also nedmalloc can give a huge performance boost to windows allocation making it almost as good as preallocations. Sometimes its better due to memory locality which reduce cache misses. The great thing about D's GC though its that other people can implement there own. I hope that when someone comes up with a really good one and it will become part of the main distribution (ie not become another windows malloc mess). -Joel
Jul 31 2008
parent JAnderson <ask me.com> writes:
JAnderson wrote:
 Walter Bright wrote:
 Sean Kelly wrote:
 All that said, I believe it's entirely possible to write 
 performance-critical code in D so long as the
 programmer is careful about memory allocation.  And as Walter has 
 said before, because even
 malloc is not time-constrained the same goes for any use of dynamic 
 memory--GCs just magnify
 the issue.  Server apps in Tango, for example, don't allocate any 
 memory at all once initialization
 is complete.  This is why they tend to be so blisteringly fast.  It's 
 also why Tango is designed the
 way it is--not always super-convenient for run of the mill apps 
 programming, but quite scalable
 for high-end work.  By contrast, I'd argue that Phobos is the opposite.

I wrote a version of Empire (the game) in D that does no allocation at all. Therefore, the gc never runs and there is never any unbounded delay. The gc is never going to pop up out of nowhere and sink your application. A gc only happens when you request memory from the gc. For the real time constrained section of code, the idea is to pre-allocate all the data you'll need first, then do no allocation within the critical section. In fact, such critical code in C++ does this anyway because there are no bounded time constraints on C++ new either. C malloc has no bound constraints, either.

This is true, new in C++ can seriously degrade performance if not manage properly. However calling a couple of 100 smallish news in C++ per frame is quite acceptable and has a infindecimal affect on performance, when working on windows.

I should point out that I'm aware of fragmentation however you can still call new's in either a way that doesn't fragment, or simply rely on paging to fix the problem. If your not creating a program that needs to run longer then a month (ie maybe your game has a maximum time limit of 30 minutes or something) then the problem is even less of an issue. If you are, make sure you understand fragmentation.
 
 D however is another kettle of fish.  You can't have any allocations 
 during the active part of the game.  You have to do it all a load 
 points.  Why? Because at some point the memory allocator will runout of 
 free memory and then it will need to clear anything that's unused. 
 Normally this wouldn't be a problem however it takes over a frame to 
 flush; and that leads to a very noticeable stutter.
 
 Now I haven't tried realtime programming with allocations in the 
 realtime part for a while so things might have changed however that's 
 how it was the last time I was playing around with that stuff.  Also I 
 haven't tried Tangos.
 
 Also nedmalloc can give a huge performance boost to windows allocation 
 making it almost as good as preallocations. Sometimes its better due to 
 memory locality which reduce cache misses.
 
 The great thing about D's GC though its that other people can implement 
 there own.  I hope that when someone comes up with a really good one and 
 it will become part of the main distribution (ie not become another 
 windows malloc mess).
 
 -Joel

Jul 31 2008
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article
 Sean Kelly:
 I am very much concerned that the "future of D" is
 as a general applications language and that its systems language roots will
 be left to rot.  And who needs another applications language, anyway?  The
 world has a million of them.



 The GC can be disabled, but you have to carry it around in the executable

you obtain from stripped C. At the moment you can't run such things on sytems with little RAM, as you can do with C.
 Regarding the hard real time systems, I think people there are scared of a GC

you can do with C that are a problem to do with D.
 Bye,
 bearophile

A few things: First of all, Pascal is from the Stone Age and therefore has had a chance to be optimized in every way feasible to make it as tight as humanly possible. DMD is a reference implementation of a relatively immature language, and right now the focus is on adding more features and fixing bugs, not on aggressive space optimization. Maybe once the dust settles a little, the GC can optionally be made a shared DLL, or excluded outright if the programmer is going to disable it anyhow, and optimizations can be added to make it more space-efficient. Second: I actually think D is a great application programming language that fills a pretty useful niche. I am a computational biologist, so my needs are basically performance, correctness and ease of use. If I wrote everything in C, C++ or (I almost don't even want to say it) Fortran, I'd never get anything done because these are such crufty old languages that are much more difficult to use than D. If I used Java or C#, I'd pay a much larger abstraction penalty, and have OOP shoved down my throat where it makes the least sense, namely small but performance-critical projects. If I used Python or Ruby, the performance penalty would just be ridiculous unless I wrote some parts in C, in which case...uh, I kind of wanted to avoid using old-school, low-level languages. Bottom line is, D gives me most of the ease of use of a high-level dynamic language and most of the performance of C or C++, and for what I do that seems like a very good tradeoff.
Jul 31 2008
next sibling parent downs <default_357-line yahoo.de> writes:
dsimcha wrote:
 Bottom line is, D gives me most of the ease of use of a high-level dynamic
 language and most of the performance of C or C++, and for what I do that seems
 like a very good tradeoff.

Couldn't agree more. --downs
Jul 31 2008
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
dsimcha:
 A few things:  First of all, Pascal is from the Stone Age and therefore has
had a
 chance to be optimized in every way feasible to make it as tight as humanly
 possible.

Yet, we're talking about a pretty modern ObjectPascal here, with a syntax quite close to the Delphi one. I have used it, and it's a good language, you can write tons of things with it, and it's way different from the C language, it has many nice modern things, and very little pointers, it's plenty fast, the IDEs are good, etc, but I understand your point and I agree. I know that D is young, etc, and if you follow this group you probably know that I like D.
 Second:  I actually think D is a great application programming language that
fills
 a pretty useful niche.  I am a computational biologist, so my needs are
basically
 performance, correctness and ease of use.

I too use D mostly for bioinformatics, I have introduced it (with Python, well Python first) in my lab that so far has used mostly Perl/Fortran/C. And I too like to use D for such purposes, sometimes Python is too much slow, and I don't want to use Cython much because for me programming in D is much simpler than keeping track of the mad reference counts in Cython programs. (But I think such purposes of D aren't exactly the same you may want from a system language this thread was talking about, you too talk about 'application programming language'). Bye, bearophile
Jul 31 2008
prev sibling next sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Thu, 31 Jul 2008 19:15:03 +0400, Helmut Leitner  
<leitner wikiservice.at> wrote:

 Walter Bright wrote:
 downs wrote:

 Walter Bright wrote:

 Steven Schveighoffer wrote:

 I would hazard to guess that adopting this would cause a larger
 rift than const.


He's probably right.

programmers in the country. The topic was a 2 day conference on how to support multithreading in C++. It soon became clear that only two people in the room understood the issues (and I wasn't one of them). I think I understand the issues now, but it has taken a long time and repeatedly reading the papers about it. It is not simple, and it's about as intuitive as quantum mechanics. I suggested to Andrei and Bartosz just the other day that I don't expect the value in this model will be readily apparent. I'm pretty sure it won't be, as the issues are hard to understand. But the issues being hard to understand is exactly why this model is needed. There are surely several articles, papers, and tutorials in this :-)

Perhaps this has already been discussed, but there seems another upcoming arms race between probably - NVIDIA/CUDA, currently available 200+ cores available at $500 - Intel multicore, probably available in 12+ months competing in - scientific number-crunching - life video encoding (hot topic) I think it would be a BIG marketing effect for D, if it could support the NVIDIA/CUDA system. Probably it would even get payed by NVIDIA. Helmut

Other system to take into an account is Playstation 3. It has 7 cores, it runs Linux (YellowDog/Ubuntu/Gentoo...), it is cheap, it is available to everyone. The PS3's hardware has also been used to build supercomputers for high-performance computing. IIRC, it used to have the best cost/GFLOPS ratio some time ago. PS3 uses a GCC compiler which is freely available (I love GPL for that reason) so a GDC is a matter of time (and some effort). BTW, gdc is already ported to Playstation Portable. As a result, we could use a PS3 as a basis for an upcoming cuncurrent programming support in D. I just don't see any other *real* possibilities to get 4 or more cores for a low price.
Jul 31 2008
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Steven Schveighoffer" wrote
 "Walter Bright" wrote
 http://www.reddit.com/comments/6u7k0/sharing_in_d/

There are 2 problems I see with this scheme. First, that the default is 'unshared'. This is going to break a lot of existing code, and make peoples lives miserable who do not want to deal with unshared non-stack data. I would hazard to guess that adopting this would cause a larger rift than const.

After thinking about this some more, I realize that this part of my argument is wrong. I was thinking since by default you can share data today, that should be the default. But most of the time, you declare things (global or otherwise) expecting them not to be shared. Shared data is usually wrapped in an object that you can synchronize on. So most existing code should work fine unless that code expects to share data with other threads. That being said, I still see issues with casting and with function calling. -Steve
Aug 01 2008
prev sibling next sibling parent Knud Soerensen <4tuu4k002 sneakemail.com> writes:
Walter Bright wrote:
 http://www.reddit.com/comments/6u7k0/sharing_in_d/

I have also posted it on my new news site http://crowdnews.eu -- Crowdnews.eu - Promote yourself and your friends!
Jul 30 2008
prev sibling next sibling parent reply "Craig Black" <cblack ara.com> writes:
If I understand it correctly, then you are going down the right path with 
this stuff.  IMO, the ultimate goal is a programming language that is 
thread-safe by default, just as a GC language is memory-safe by default.  I 
sounds like you may need to flesh things out quite a bit to attain a 
comprehensive solution for thread safety.  Keep in mind, there should always 
be ways to subvert safety when necessary for performance.

-Craig 
Jul 31 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Craig Black wrote:
 If I understand it correctly, then you are going down the right path with 
 this stuff.  IMO, the ultimate goal is a programming language that is 
 thread-safe by default, just as a GC language is memory-safe by default.

You aren't the first to note the analogy to GC!
 I sounds like you may need to flesh things out quite a bit to attain a 
 comprehensive solution for thread safety.  Keep in mind, there should always 
 be ways to subvert safety when necessary for performance.

Of course - casting a shared type to unshared means subverting any compiler guarantees, just like when const is cast away.
Jul 31 2008
parent superdan <super dan.org> writes:
Walter Bright Wrote:

 Craig Black wrote:
 If I understand it correctly, then you are going down the right path with 
 this stuff.  IMO, the ultimate goal is a programming language that is 
 thread-safe by default, just as a GC language is memory-safe by default.

You aren't the first to note the analogy to GC!

yeh i could swear i read an article about that. was his name grosh or so? interesting shit that was. i finally read bartosz' stuff. the basic idea looks cool. i bet there will be much kinks to work out tho. fwiw perl does similar shit in one of its many attempts at threads. aside from being slow like molasses in the winter the model is clean. problem is perl must duplicate a lot more shit than d has. so things stand good for d. pooling will help a ton too.
Jul 31 2008
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 http://www.reddit.com/comments/6u7k0/sharing_in_d/

Sounds like the addition of a thread-local storage class (which I've been asking for since I discovered D), plus some language checking on top of that. I'll admit to being somewhat concerned that the checking aspect will incur an unwanted runtime expense, as I don't believe there's any way at compile-time to detect that a variable is being accessed by multiple threads. One could try to assert that non-shared data may never be used in synchronized blocks, but not all data used in such blocks is actually shared. In short, I'd love a "thread" storage class, as always, and would be curious to see how the rest turns out. It sounds unlikely to work, but who knows. That said, data can be shared in one of two ways: either it may be referenced via a static or global variable or it may be explicitly passed between two threads. The latter case is typically safe because it's deliberate while the former may well not be. Thus, the easiest way to get all this working would be to forbid the use of "static" in a multithreaded app, or add checking to "static" so it acts like "shared." That eliminates the need for a new keyword and makes existing apps all compile correctly by default. The final step would be to require that all static functions either be atomic or contain a "synchronized" statement. Easy to do at compile-time and it would get the job done for the most part. It's too bad we've been unable to talk about any of this offline. We've been considering doing a lot of this sort of thing with Tango for years now but had been avoiding any unnecessary runtime changes in hopes that it would increase the likelihood that the powers that be would get involved. Obviously, that idea failed :-) But I'll take this as implicit permission to have at it, since you seem to be talking along roughly similar lines for D2 anyway. Sean
Jul 31 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 Sounds like the addition of a thread-local storage class (which
 I've been asking for since I discovered D),

It's actually implemented in D 2.0 as the __thread storage class, however it's for testing purposes only.
 plus some language
 checking on top of that.  I'll admit to being somewhat concerned
 that the checking aspect will incur an unwanted runtime expense,
 as I don't believe there's any way at compile-time to detect that
 a variable is being accessed by multiple threads.

It's done statically by the type - a shared type can be accessed by multiple types, an unshared type cannot.
 It's too bad we've been unable to talk about any of this
 offline.  We've been considering doing a lot of this sort
 of thing with Tango for years now but had been avoiding any
 unnecessary runtime changes in hopes that it would increase
 the likelihood that the powers that be would get involved.
 Obviously, that idea failed :-)  But I'll take this as
 implicit permission to have at it, since you seem to be
 talking along roughly similar lines for D2 anyway.

We've been talking about doing it as a static type system, not as a runtime one. Bartosz mentioned that there are ways to do it at runtime, but there are a lot of issues that would need to be worked out for that.
Jul 31 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Sean Kelly wrote:
 Sounds like the addition of a thread-local storage class (which
 I've been asking for since I discovered D),

however it's for testing purposes only.

Yeah, I saw that. If only it were in D 1.0 :-)
 plus some language
 checking on top of that.  I'll admit to being somewhat concerned
 that the checking aspect will incur an unwanted runtime expense,
 as I don't believe there's any way at compile-time to detect that
 a variable is being accessed by multiple threads.

multiple types, an unshared type cannot.

What about this: shared ClassA a; void main() { ClassB b = a.getB(); b.mutate(); } I'd imagine the checking will catch common mistakes but not issues like the above? Or will the fact that 'b' is being returned from a require the declaration of 'b' to be shared because the value may be accessed by both ClassA and anything outside ClassA? Sean
Jul 31 2008
next sibling parent reply downs <default_357-line yahoo.de> writes:
Sean Kelly wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Sean Kelly wrote:
 Sounds like the addition of a thread-local storage class (which
 I've been asking for since I discovered D),

however it's for testing purposes only.

Yeah, I saw that. If only it were in D 1.0 :-)

1.0 has tools.threads' TLS!(), so you can use that :) It works under win32 and posix. </tools_ad> --downs
Aug 01 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"downs" <default_357-line yahoo.de> wrote in message 
news:g6ufic$1hj4$2 digitalmars.com...
 Sean Kelly wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Sean Kelly wrote:
 Sounds like the addition of a thread-local storage class (which
 I've been asking for since I discovered D),

however it's for testing purposes only.

Yeah, I saw that. If only it were in D 1.0 :-)

1.0 has tools.threads' TLS!(), so you can use that :) It works under win32 and posix. </tools_ad> --downs

You do realize (1) you're advertising to one of the main Tango devs, and (2) Tango already has thread-local storage.
Aug 01 2008
parent downs <default_357-line yahoo.de> writes:
Jarrett Billingsley wrote:
 "downs" <default_357-line yahoo.de> wrote in message 
 news:g6ufic$1hj4$2 digitalmars.com...
 Sean Kelly wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 Sean Kelly wrote:
 Sounds like the addition of a thread-local storage class (which
 I've been asking for since I discovered D),

however it's for testing purposes only.


and posix. </tools_ad> --downs

You do realize (1) you're advertising to one of the main Tango devs, and (2) Tango already has thread-local storage.

Um. Well, yeah, I realize that _now_ :) Sorry for that misunderstanding.
Aug 01 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sean Kelly wrote:
 What about this:
 
     shared ClassA a;
 
     void main()
     {
         ClassB b = a.getB();
         b.mutate();
     }
 
 I'd imagine the checking will catch common mistakes but not issues
 like the above?  Or will the fact that 'b' is being returned from
 a require the declaration of 'b' to be shared because the value
 may be accessed by both ClassA and anything outside ClassA?

Shared cannot be implicitly cast to unshared. Just like const cannot be implicitly cast to mutable.
Aug 01 2008
parent reply Russell Lewis <webmaster villagersonline.com> writes:
Walter Bright wrote:
 Shared cannot be implicitly cast to unshared. Just like const cannot be 
 implicitly cast to mutable.

But you can implicitly cast unshared to shared, right?
Aug 07 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Russell Lewis" wrote
 Walter Bright wrote:
 Shared cannot be implicitly cast to unshared. Just like const cannot be 
 implicitly cast to mutable.

But you can implicitly cast unshared to shared, right?

No. There is no implicit casting or else you can have data that is shared and unshared at the same time. It will be up to the coder to ensure only one is happening at a time. -Steve
Aug 07 2008
parent reply Russell Lewis <webmaster villagersonline.com> writes:
Steven Schveighoffer wrote:
 "Russell Lewis" wrote
 Walter Bright wrote:
 Shared cannot be implicitly cast to unshared. Just like const cannot be 
 implicitly cast to mutable.


No. There is no implicit casting or else you can have data that is shared and unshared at the same time. It will be up to the coder to ensure only one is happening at a time.

Yeah, I saw your (was it you?) example of how that would become problematic. Did you see my "scope locks" idea as a possible way to safely move data between the shared & unshared realms?
Aug 07 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Russell Lewis" wrote
 Steven Schveighoffer wrote:
 "Russell Lewis" wrote
 Walter Bright wrote:
 Shared cannot be implicitly cast to unshared. Just like const cannot be 
 implicitly cast to mutable.


No. There is no implicit casting or else you can have data that is shared and unshared at the same time. It will be up to the coder to ensure only one is happening at a time.

Yeah, I saw your (was it you?) example of how that would become problematic. Did you see my "scope locks" idea as a possible way to safely move data between the shared & unshared realms?

I think there may be no middle ground, as in order for locks to work, every access to a locked variable must be through the lock. If you have 2 references to a variable, one that is shared and one that is not, locking on the shared variable does nothing to prevent the unshared variable from being accessed without the lock. I think the middle ground simply needs to do the most safe thing (i.e. treat as shared), but not allow implicit casting to unshared or shared. However, in this case, you incur a possible performance hit when it might not be necessary. It might be that the middle ground is simply undesirable, so you have to do explicit casting. I'm not sure. -Steve
Aug 08 2008
parent Russell Lewis <webmaster villagersonline.com> writes:
Steven Schveighoffer wrote:
 I think there may be no middle ground, as in order for locks to work, every 
 access to a locked variable must be through the lock.  If you have 2 
 references to a variable, one that is shared and one that is not, locking on 
 the shared variable does nothing to prevent the unshared variable from being 
 accessed without the lock.
 
 I think the middle ground simply needs to do the most safe thing (i.e. treat 
 as shared), but not allow implicit casting to unshared or shared.
 
 However, in this case, you incur a possible performance hit when it might 
 not be necessary.  It might be that the middle ground is simply undesirable, 
 so you have to do explicit casting.

I think that you misunderstood my locking idea. My idea was that there was only one root reference to a variable, and you have to grab the lock to get to it. So you can treat it as unshared while you hold the lock (with all the performance benefits, and code conveniences like ++, that you get with unshared data) but while you do not hold the lock it is absolutely inaccessible. Put more explicitly, a "locked" variable has three modes: shared, in accessible to all locked in read mode, unshared const scope to one thread locked in write mode, unshared scope to one thread Of course, you can't have external pointers pointing into the data structure (from outside the lock), but inside the lock it's perfectly OK to have pointers to other things inside the lock (or to external shared data). So you could, for instance, build a doubly-linked list; you just make the sure that your global variable, which points to the head of the list, is declared as "locked".
Aug 08 2008
prev sibling next sibling parent "Koroskin Denis" <2korden gmail.com> writes:
On Thu, 31 Jul 2008 04:52:16 +0400, Walter Bright  
<newshound1 digitalmars.com> wrote:

 http://www.reddit.com/comments/6u7k0/sharing_in_d/

Hello, volatile! :)
Jul 31 2008
prev sibling next sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Wed, 30 Jul 2008 17:52:16 -0700, Walter Bright wrote:

 http://www.reddit.com/comments/6u7k0/sharing_in_d/

I haven't done much threading, so this sounds mostly good. On question I have relates to when a single threaded program/component is using libraries designed to support multithreading (thus it asks for a shared value). You aren't really doing any sharing you just wanted to call the function for what it does. Would this never happen? Do I now have to cast my unshared to shared even though I'm not interested in sharing? My main point, is that if I'm writing a single threaded program, I shouldn't care about sharing even if the library I'm using does.
Jul 31 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Jesse Phillips wrote:
 Would this never happen? Do I now have to cast my unshared to shared even 
 though I'm not interested in sharing? My main point, is that if I'm 
 writing a single threaded program, I shouldn't care about sharing even if 
 the library I'm using does.

Unshared can be implicitly cast to shared, so you shouldn't have to.
Jul 31 2008
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:

 http://www.reddit.com/comments/6u7k0/sharing_in_d/

When can we expect to see this in D2? For the first time since moving to Tango, I'm considering moving back to Phobos. A monolithic garbage collector kills scalability for my data intensive application. Of couse all interesting hardware is 64 bit, so I may need to be more patient...
Aug 04 2008
parent Walter Bright <walter nospamm-digitalmars.com> writes:
Jason House Wrote:
 When can we expect to see this in D2? For the first time since moving to
Tango, I'm considering moving back to Phobos.

It'll come in stages. For example, D 2.0 already supports thread local storage for globals. Next will probably come the 'sharing' type constructor, and name mangling. All this will phase in over the next 3 months or so.l
Aug 04 2008