By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,460 Members | 1,508 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,460 IT Pros & Developers. It's quick & easy.

Multi-threading, race conditions and managed code

P: n/a
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.
Jul 1 '08 #1
Share this Question
Share on Google+
2 Replies


P: n/a
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.
Jul 1 '08 #2

P: n/a
<ia*******@gmail.comwrote:
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?
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.)

--
Jon Skeet - <sk***@pobox.com>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon_skeet
C# in Depth: http://csharpindepth.com
Jul 1 '08 #3

This discussion thread is closed

Replies have been disabled for this discussion.