On 2011-11-28 11:48:17 +0000, Debdatta <debdatta.bas...@gmail.com> said:
I get it now. Totally. This is like a mechanism to enable
shared-correctness. Just like const correctness in c++. :D
This does allow for some nice static runtime checks to ensure that the
code is free of races. But I somehow still like the deafult is shared
idiom.
To be fair i never use const correctness features in c++ either. :P
In my (limited) experience, involving mostly threading for performance,
sharing is the norm.( Take a look at .NET's task parallel library, or
intel's TBB.)
the point i am trying to make is that restricting access to thread
specific data is far simpler than keeping track of what is shared. this
is
because shared data is usually all over the place when you want to
thread for performance. However, thread local data resides in one
place( the
thread class mostly).
Look at the example I gave a few posts back:
class MyThread : Thread
{
public:
void run;
private:
//any data i put here can only be seen by the current thread.
}
Keeping this in mind, whats the rationale for no default sharing?
Actually, the private data of your thread object could be used by other
threads if the MyThread object is accessible from another thread and
someone calls a method on it. Or you might have a MyThread object
instance messing with the variables of another instance. Hopefully the
methods of the MyThread object would be careful about not sharing the
private data with other threads, but that's no guaranty.
Also, you'll likely call external functions from your thread's main
function: how do you know they are thread-safe, that they aren't using
mutable global variables? Or that they aren't storing their input data
elsewhere? With the no default sharing rule, they'll always be
thread-safe (unless they circumvent the type system), both in their
global state and with the data you provide to them.
Not having default sharing is about providing guaranties, it's about
making thread-safety checkable by the compiler. The implementation we
have is not perfect (it hampers a couple of patterns), but hopefully
that can be improved.
Also take note of this: Private isn't the same in D as in C++. Private
means module-private: D won't prevent other code from accessing
MyThread's private members as long as this other code is in the same
module.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
