469,904 Members | 2,065 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,904 developers. It's quick & easy.

ReaderWriterLock - static declaration necessary?

Hi,

I'd like to know if it's possible/responsible to use the ReaderWriterLock
class (RWL) in a class without declaring it as "static". The example in the
SDK does not use a static RWL. However, the documentation has the standard
disclaimer of "Any public static members of this type are safe for
multithreaded operations. Any instance members are not guaranteed to be
thread safe." And the members of this class are not static, so all of
ReaderWriterLock methods are unsafe for multithreaded operations? Seems
like RWL is not terribly useful! Should I assume the docs are wrong?

I can make the instance of the RWL class static in the class containing it,
which I believe will have approx. the same effect as making the methods
static (at least for operations between the instances of the containing
class)? Moreover, the example at (
http://msdn.microsoft.com/library/de...ClassTopic.asp )
, it indicates that declaring the ReaderWriterLock static makes it visible
to all threads. Which implies it's not visible if it's not static? <blink,
blink>

Any insight into the behavior of RWL would be helpful - any links to
articles, ect. would be much appreciated. I've found a few articles on the
subject, but none go into enough detail into the inner workings of RWL to be
of much help. I'm thoroughly confused.

Regards,
Tyrion
Nov 15 '05 #1
2 1543
Tryion <Tyrion@_nowhere_.com> wrote:
I'd like to know if it's possible/responsible to use the ReaderWriterLock
class (RWL) in a class without declaring it as "static". The example in the
SDK does not use a static RWL. However, the documentation has the standard
disclaimer of "Any public static members of this type are safe for
multithreaded operations. Any instance members are not guaranteed to be
thread safe." And the members of this class are not static, so all of
ReaderWriterLock methods are unsafe for multithreaded operations? Seems
like RWL is not terribly useful! Should I assume the docs are wrong?
I think so - there are other places where that doc comment appears
despite other documentation saying it's fine.
I can make the instance of the RWL class static in the class containing it,
which I believe will have approx. the same effect as making the methods
static (at least for operations between the instances of the containing
class)?
No, that won't have the same effect at all. It's a property of the
methods themselves as to whether or not they're thread-safe, not
whether or not a variable containing a reference to an instance is
static or not.

Moreover, the example at (
http://msdn.microsoft.com/library/de...us/cpref/html/
frlrfSystemThreadingReaderWriterLockClassTopic.asp )
, it indicates that declaring the ReaderWriterLock static makes it visible
to all threads. Which implies it's not visible if it's not static? <blink,
blink>


I think that's just a very poor doc comment, really. It has to be
static because everything's static! No instances are created...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 15 '05 #2
Thanks for the info, John. Good to know I'm not the only one confused by
the docs, at least. I'm going to go ahead and use a non-static
declaration. But I'm feeling the need to test it more than I was originally
planning to. If I find anything, errrr- interesting, I'll post it. <g>
Nov 15 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by Bryan Parkoff | last post: by
2 posts views Thread by pokémon | last post: by
9 posts views Thread by Christian Christmann | last post: by
14 posts views Thread by Jess | last post: by
11 posts views Thread by Jef Driesen | last post: by
1 post views Thread by Waqarahmed | last post: by
reply views Thread by Salome Sato | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.