Re: .NET Poor threading architecture?
- From: "Willy Denoyette [MVP]" <willy.denoyette@xxxxxxxxxx>
- Date: Wed, 14 Jun 2006 20:26:16 +0200
"WXS" <WXS@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:77230348-7B5E-4874-8C74-716E79D5420D@xxxxxxxxxxxxxxxx
|> Suspend/Resume are made obsolete just because of this "the willingness to
| > correct". These API's are calling the Win32 counterparts which are:
| > - not designed to be used from user code [see MSDN - SuspendThread API
<This
| > function is primarily designed for use by debuggers. It is not intended
to
| > be used for thread synchronization>]
|
| >>>> These Win32 API's have been used for years (not for thread
synchronization), but for thread control (forget synchronization that is not
the intention, thread control is). By default threads are suspended and
must be resumed and the MFC/Win32 level for example which is used in almost
all threading cases. User code uses them all the time.
| You need to be able to control your threads in .NET for various reasons,
| these API's are sometimes critical and the only means for a developer to
| accomplish specific functionality. I think they should make them so
suspend
| would stop the thread at a safe point from .NET's perspective and leave
the
| rest of the safety to the developer.
This is exactly what the CLR does, calling 'SuspendThread' and
'ResumeThread' at a safe spot, but that doesn't mean it has to be done from
"managed" user code that runs in top of the CLR.
When using MFC and Win32 you are at a different level in user space, using
Win32 you are directly controlling OS threads from your code (just like the
CLR does), when you call SuspendThread you ask the OS to suspend the OS
thread, you are assumed to know the pittfals and take measures to prevent
all sort of issues and bugs (T in Threading spell for Troubles, most of the
multithreaded applications are buggy). In managed code you aren't controling
(nor should you) OS threads, you are using "logical threads" that map to
something that might be an OS thread, but can even so be something else
(like a fiber). IMO it's up to the CLR and the FCL to make threading less
error prone and more (safely) accessible than under native code, so it's
better to remove these services, provided there are more safe alternatives,
as there are.
| > As for your suggestion to make WinFX the primary OS API, don't forget
that
|
| >>>> That's not my suggestion I heard MS has proposed that will be the
case in a future OS version. I agree with you... it is unreasonable.
Really, any signs that David Cutler going to retire? :-)) Mind to share the
source of such proposition? I know that Vista and Longhorn Server are still
Win32 based. IMO Win32 will survive the CLR, but as always - only the future
will tell.
Willy.
.
- Follow-Ups:
- Re: .NET Poor threading architecture?
- From: WXS
- Re: .NET Poor threading architecture?
- References:
- Re: .NET Poor threading architecture?
- From: Willy Denoyette [MVP]
- Re: .NET Poor threading architecture?
- From: WXS
- Re: .NET Poor threading architecture?
- Prev by Date: Re: Asynch Sockets over UDP: How do you Know when a socket dissconnects
- Next by Date: Re: What is the difference between Managed and Unmanaged resources in regards to IDisposable
- Previous by thread: Re: .NET Poor threading architecture?
- Next by thread: Re: .NET Poor threading architecture?
- Index(es):
Relevant Pages
|