Re: .NET Poor threading architecture?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

First point is my understanding is suspending is not safe even from a CLR
perspective right now (they tried to suspend in a safe place but mostly only
relative to garbage collection).

If the above is true at least fix that and let me deal with the user mode
problems.
Sure MS could protect me from myself some more by tying my shoelaces
together so I can't go to work in the morning either, but is that really
productive?! From that point of view lets deprecate main() and solve all of
our problems :)

If .NET is going to abstract threads to .NET threads for us, it needs to
provide us a safe control method, to control those threads from external
points.

Did I mis-hear that the intention is to make WinFX the primary windows
subsystem and win32 secondary sort of like how win32 has been the primary and
posix has been a secondary subsytem, could be I misheard or misunderstood.

In either case if .NET is to be a reach full feature plaform/API
substitution for Win32 (which otherwise it seems to have every intention of
being), you need external thread controls.




"Willy Denoyette [MVP]" wrote:


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



.

Relevant Pages

  • Re: .NET Poor threading architecture?
    ... | First point is my understanding is suspending is not safe even from a CLR ... Well largely it relates to GC, but the CLR uses these Win32 API's to control ... exactly when to suspend because the JIT marks the safe points to do so. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: .NET Poor threading architecture?
    ... Some additional research into this does suggest they could make it safe ... Well largely it relates to GC, but the CLR uses these Win32 API's to control ... exactly when to suspend because the JIT marks the safe points to do so. ... unmanaged code, after all ISO/C++ is stall part of VS, right?. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: .NET Poor threading architecture?
    ... the intention, thread control is). ... "managed" user code that runs in top of the CLR. ... When using MFC and Win32 you are at a different level in user space, ... when you call SuspendThread you ask the OS to suspend the OS ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: System Timer Callback?
    ... This is not specifically about the MCI control, ... functions that suspend the event processing, leading to a very Ad Hoc ... collection of loops containing "DoEvents". ... Asynchronous normally means it moves everything off to a background thread and allows your code to carry on as before, but there are some exceptions that will just call Doevents allowing other code to run, but STILL blocking your thread of execution. ...
    (microsoft.public.vb.general.discussion)
  • Re: hitting C-s
    ... I'm assuming C-s is for suspend. ... ASCII control characters has virtually no mnemonic association. ... could have a Paper Tape reader and a Paper Tape punch. ...
    (comp.unix.questions)