Re: Should we always call EndInvoke()?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

hi


On Feb 3, 5:12 am, "Peter Duniho" <NpOeStPe...@xxxxxxxxxxxxxxxx>
wrote:
On Mon, 02 Feb 2009 15:46:12 -0800, <beginwi...@xxxxxxxxx> wrote:
I wasn’t asking about thread safe instances, but more about thread
safe static .Net members. Just like your regular, non-god like
programmer  has to make sure that all the different thread-safe
members belonging to different classes have to access same resource in
some synchronized way, I thought the creators ( demigods :D ) of Net
library also made sure that static members from different classes
accessed same resource in some synchronized manner

I have never heard of a class that documents itself as "thread-safe" with  
respect to some _other_ class.  Not that classes couldn't share resources,  
but it's unusual enough for them to do so as it is, never mind for two or  
more classes to claim thread-safety with each other.

One of the points of object-oriented programming is to isolate  
implementation details within a class.  When that's done, different  
classes are automatically thread-safe with respect to each other, because  
they don't interact with each other in a thread-unsafe way.


Despite the ability of classes to isolate implementation details,
there is still possibility of different classes ( those defined in Net
library) trying to operate on same resource at the same time, and if
OS doesn’t synchronize them somehow, then wouldn’t it be possible for
data to get corrupted ( I’m assuming that’s what you meant with the
term “interact with each other in a thread-unsafe way” ) … in other
words, classes would interact with each other in a thread-unsafe way?!


cheers

.

Relevant Pages

  • Re: Should we always call EndInvoke()?
    ... safe static .Net members. ... When that's done, different classes are automatically thread-safe with respect to each other, because they don't interact with each other in a thread-unsafe way. ... If one did, it would not be documented as being thread-safe relative to DriveInfo (the GetDrives() method or otherwise). ... In this case, the list returned by GetDrives() could easily show both drives present at the same time, when in fact they were never installed on the system at the same time. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: visibility on array elements
    ... AtomicLongArray and go with a long(the reason is ... when accessing the elements of the array: ... synchronize on the individual elements, ... itself guarantee "thread-safe behavior." ...
    (comp.lang.java.programmer)
  • Re: How do I use the Java API in a Thread-Safe Manner?
    ... it's not necessary to synchronize the `new' operator. ... > You probably need to synchronize access to `sbStr', ... declared as a local variable (which would make it it thread-safe, ... since that means every other piece of Java code ...
    (comp.lang.java.programmer)
  • Re: How do I use the Java API in a Thread-Safe Manner?
    ... assume that the API is *not* thread-safe unless it states that it is (such ... If the API is ... method, call it UnsafeAPI() that is not thread-safe, therefore ... ... stated above when you said "There's no effective way to synchronize access ...
    (comp.lang.java.programmer)
  • Re: Does C# have static local variables like C++?
    ... local static variable is not safe for multi threaded applications. ... I suppose one other argument is that in other cases, it should be more clear to the programmer that the use of the data is not thread-safe, whereas a static local may not be readily apparent to a programmer as not being thread-safe. ...
    (microsoft.public.dotnet.languages.csharp)