Concurrency.

Debdatta debdatta.basu91 at gmail.com
Mon Nov 28 04:57:29 PST 2011


@Michael,

Thanks for clearing that up. Your post was very informative. :)

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

Absolutely! However I presume that any self respecting programmer will not manipulate shared data without planning it, or at least thinking about
it. :D Any self respecting coder would know about memory boundaries, and not arbitrarily modify shared data.

>>Not having default sharing is about providing guaranties, it's about
>>making thread-safety checkable by the compiler.

No piece of code can absolutely guarantee threading errors. When you start a thread you are most likely doing it because you want to manipulate
shared data. If you wanted complete memory isolation, with the only means of communication being messages, you would create processes, not threads.
I understand that this is an over generalization, and the current no default sharing idiom provides less isolation than processes, yo get the drift.
:D

Threads within a process, by definition(in this case the os defines them), operate within a shared memory space. I don't understand the need to add
an extra level of complexity in the code, as well as the compiler, by abstracting something thats inherant to the os.

Its like const correctness. You can write more concise, perfectly working programs without it. and all it gives you is an extra check on whether a
function will modify something, which I, as a programmer, already know. You may interpret my comments as me not wanting to give up control to the
compiler. In that sense, even a GC is abstracting something thats inherant to the os. :D But the GC gives a huge return on investment, and I don't
see how the no default sharing rule does.

-Debdatta Basu.



More information about the Digitalmars-d mailing list