There can be no "final points" in this discussion!
From a practical perspective, I most heartily disagree. Single-threading is a much
simpler model to work in, and unless the language / environment makes it 100%
transparent that we're not single-threaded we'll have so many bugs it simply isn't
possible that we'll have better systems in the end by doing this.
The practical effect of your suggestion is that every method must lock at the
beginning and unlock at the end. (You even have a bug in your suggestion -- you say
to lock "if they wanted to do more than one thing." Even setting just (e.g.) the Left
property has to lock, else you will be ignoring the lock placed by another thread that
wants to do a read-modify-write of the Left property.)
In Java(tm) you can declare an object to be Synchronized, in which case the runtime
doesn't let multiple threads work with it at the same time. I believe it does that by
turning every method into the equivalent of
lock this;
try
{method code}
finally
unlock this;
which is what I think is necessary. The slowdown in Java resulting from using
Synchronized objects, even when there's only one thread, is substantial. In my view,
it is not reasonable to impose that overhead on every object managed by the runtime;
and the alternative is to rely far too much on us feeble programmers.
So far, we haven't even talked about the possibility of deadlock, which will happen
quite frequently unless something is done to prevent it -- adding even more overhead.
It would probably make more sense -- and perhaps even be possible to implement -- for
the runtime to turn all calls made from MTA threads into calls done via Invoke,
transparently. (But that would be silly when the call is being made to an object
that's only used within this thread; it adds lots of overhead when one supposed
advantage of threads is to improve performance. How do we know if the object is ever
going to be used from another thread?) Also, the MTA thread will often want to be
making asynchronous calls, and the programmer would have to represent that with
different syntax (until we implement the compiler switch /mindmeld so it knows which
calls should be asynch by reading our minds).
I don't wish for the more complex world you envision.
At 10:57 PM 2/25/2004, Jade Burton wrote (in part)
>Thanks Shawn, your insight has been analysed :) and after a bit of playing
>around with some hypothetical architectures I have to agree with you. I did
>end up with a message loop..
>
>If I were to boil-down my original rant to its essence, I would still say
>this, however: wouldn't it be great if the UI thread wasn't tagged as STA,
>but rather that it was just like any old thread? This would mean you still
>have a single thread dispatching events to event handers, but your window
>objects would instead be written to be 100% threadsafe and, for example, you
>could Move a window to a new location by:
>
>myForm.Left = 77;
>
>from *any* thread, *without* using Invoke(). (Which evidently I have an
>aversion to :p ) Yes the programmer would have to use lock { } if they
>wanted to do more than one thing to the window and have it be atomic (like
>myForm.Left = myForm.Left + 77, for example), but to me the real problem
>here is that we still *have* unthreadsafe code in the first place.
>
>For example, the concept of Unsafe code in C# is probably going to be
>phased-out altogether at some point in the future. It's not inconceivable
>to me that unthreadsafe code will also be phased out in this way, making way
>for a truly unified system (i.e. not MTA|STA with a line down the middle.)
>If that's hard for the programmer to do in terms of sync plumbing etc. then
>perhaps the language itself is defficient?
>
>Anyway I just had to add that final point; sorry if this has bored anyone :|
>
>Jade Burton
>[snip]
J. Merrill / Analytical Software Corp
===================================
This list is hosted by DevelopMentorŪ http://www.develop.com
Some .NET courses you may be interested in:
NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles
http://www.develop.com/courses/gaspdotnetls
View archives and manage your subscription(s) at http://discuss.develop.com
