Re: Thread safety
From: Steve McLellan (sjm.NOSPAM)
Date: 05/27/04
- Next message: oj: "Re: Stored procedure parameter output value"
- Previous message: Justin Rogers: "Re: Thread safety"
- In reply to: Justin Rogers: "Re: Thread safety"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 27 May 2004 01:07:34 +0100
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
"Justin Rogers" <Justin@games4dotnet.com> wrote in message
news:OC$Xsw3QEHA.396@TK2MSFTNGP12.phx.gbl...
> 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.
>
>
> --
> Justin Rogers
> DigiTec Web Consultants, LLC.
> Blog: http://weblogs.asp.net/justin_rogers
>
> "Steve McLellan" <sjm.NOSPAM AT fixerlabs DOT com> wrote in message
> news:ObCcHt3QEHA.3528@TK2MSFTNGP09.phx.gbl...
> > 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
> >
> > "Justin Rogers" <Justin@games4dotnet.com> wrote in message
> > news:e5ZtEn3QEHA.2400@tk2msftngp13.phx.gbl...
> > >
> >
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdicpp/GDIPlus/sec_gdiplus.asp?frame=true
> > >
> > > Info on thread safety. Internally Height always calls methods to get
the
> > height
> > > and no caching is performed. Since each call is a method, there might
be
> > some
> > > work, the return of an ObjectBusy status, or any number of other items
> > that
> > > might go wrong.
> > >
> > >
> > > --
> > > Justin Rogers
> > > DigiTec Web Consultants, LLC.
> > > Blog: http://weblogs.asp.net/justin_rogers
> > >
> > > "Steve McLellan" <sjm.NOSPAM AT fixerlabs DOT com> wrote in message
> > > news:%23jr4ci3QEHA.3532@TK2MSFTNGP12.phx.gbl...
> > > > 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
> > > >
> > > >
> > >
> > >
> >
> >
>
>
- Next message: oj: "Re: Stored procedure parameter output value"
- Previous message: Justin Rogers: "Re: Thread safety"
- In reply to: Justin Rogers: "Re: Thread safety"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|