Thread safety

  • Thread starter Thread starter Steve McLellan
  • Start date Start date
S

Steve McLellan

Hi,

I've just discovered that accessing Image.Height (and probably other
properties) in a multi-threaded environment can cause access problems (as a
test, you can spawn a hundred threads and get them all to perform a couple
of multiplications on an image's height and width ). I know I can prevent
simultaneous access, but is there any reason why Image can't be accessed
like this? And is this common for all .NET objects? I know the docs say 'not
thread-safe' but not being safe for multiple reads seems bizarre.

Steve
 
OK, cheers. Just the sort of thing I need to find out at 1am :-) Is this
common to the framework? I'm never likely to know what's cached and what
isn't for a given property.... and surely this is unnecessary if there are
only read operations going on? I'm still not sure why exactly that could
ever be a problem.

Steve
 
Image is abstracting you from a bunch of method calls. In GDI+ each object
is simply a pointer or handle, and you call methods to get the information from
those handles. If Image cached the values for you, then it would have a bunch
of state work to handle for things like moving to the next frame or other events
that could possibly change the height or width of the underlying image.

This generally isn't a huge problem across the framework, but is common when
API's are created that are wrapping an unmanaged API. The unmanaged API's
simply have semantics that don't translate 1 for 1 into the .NET world.
 
Splendid explanation. That does kind of make sense, and it's a good job we
spotted it now (and didn't put it into our 'strange but true' bug file) and
not after release. My TV show "When multithreading goes bad" is coming on
leaps and bounds.

Thanks again, and I hope it's not as late where you are as it is here :-)

Steve
 
Back
Top