Multi-threading, race conditions and managed code

  • Thread starter Thread starter ian.cross
  • Start date Start date
I

ian.cross

Hi everyone,

If a multi-threaded .NET program creates a race condition updating a
List (for example), could this cause a memory leak/overwritten memory/
access to another objects' private memory? Basically I'd like to know
if sloppy multi-threaded code can break the CLR's guarantees of
'managed code' - garbage collection, bounds-checking, type safety etc?

First time poster, long time reader - be gentle.
 
If a multi-threaded .NET program creates a race condition updating a
List (for example), could this cause a memory leak/overwritten memory/
access to another objects' private memory?
Click to expand...

Memory leak: yes, but this has nothing to do with multithreading per se.
Just because you've got garbage collection doesn't mean a program can't have
a memory leak. Garbage collection reclaims the memory of all objects that
are no longer reachable -- so indefinitely keeping references to objects is
the managed equivalent of a memory leak.
Basically I'd like to know
if sloppy multi-threaded code can break the CLR's guarantees of
'managed code' - garbage collection, bounds-checking, type safety etc?
Click to expand...
No, no, and no, hence the "managed" part.

What can break the CLR's guarantees is unsafe code -- mucking around with
pointers and calling unmanaged functions. These actions require a full-trust
environment.

The biggest danger with multithreading is leaving objects in an inconsistent
state. This can happen because maintaining invariants under multithreading
is much harder, so it's far easier to break classes even without explicit
access to internal state.
 
If a multi-threaded .NET program creates a race condition updating a
List (for example), could this cause a memory leak/overwritten memory/
access to another objects' private memory? Basically I'd like to know
if sloppy multi-threaded code can break the CLR's guarantees of
'managed code' - garbage collection, bounds-checking, type safety etc?
Click to expand...

No, it shouldn't be able to do any of that. If you're using unsafe code
there are slightly more ways of shooting yourself in the foot, but just
threading won't have those effects. (That's not to say there aren't
weird effects that can happen, but not like that.)
 
Back
Top