ia*******@gmail.com wrote:
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?
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?
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.
--
J.
