Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
CODE PROJECT For Those Who Code
  • Home
  • Articles
  • FAQ
Community
  1. Home
  2. General Programming
  3. C#
  4. ReaderWriterLock

ReaderWriterLock

Scheduled Pinned Locked Moved C#
questionlearning
4 Posts 4 Posters 1 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • T Offline
    T Offline
    the_jat
    wrote on last edited by
    #1

    Hi everyone! I wanted to know how the ReaderWriterLock determines what is the "resource" in the code on which it has to accquire the reader lock or the writer lock, or how exactly does these locks work(internally). The MSDN article protects an static integer, but doesn't seem to specify how, as after acquiring a reader lock, writes can be done as in the following code:

    ReaderWriterLock rw = new ReaderWriterLock();
    int counter = 0;
    try
    {
    rw.AcquireReaderLock(100);
    try
    {
    Interlocked.Increment(ref counter);
    }
    finally
    {
    rw.ReleaseLock();
    }
    }
    catch (ApplicationException)
    {
    Console.WriteLine("Failed");
    }
    Console.WriteLine(counter);

    here we are acquiring an reader lock for 100ms, but writing to the data. Confused :doh:

    L J M 3 Replies Last reply
    0
    • T the_jat

      Hi everyone! I wanted to know how the ReaderWriterLock determines what is the "resource" in the code on which it has to accquire the reader lock or the writer lock, or how exactly does these locks work(internally). The MSDN article protects an static integer, but doesn't seem to specify how, as after acquiring a reader lock, writes can be done as in the following code:

      ReaderWriterLock rw = new ReaderWriterLock();
      int counter = 0;
      try
      {
      rw.AcquireReaderLock(100);
      try
      {
      Interlocked.Increment(ref counter);
      }
      finally
      {
      rw.ReleaseLock();
      }
      }
      catch (ApplicationException)
      {
      Console.WriteLine("Failed");
      }
      Console.WriteLine(counter);

      here we are acquiring an reader lock for 100ms, but writing to the data. Confused :doh:

      L Offline
      L Offline
      Luc Pattyn
      wrote on last edited by
      #2

      Hi, a ReaderWriterLock, just like all other synchronization tools, is just a tool; you must use it correctly in order to achieve your goals. It does not protect you, or any of your objects, against programming mistakes. For the RWL that means you must use it where ever you access the object you want protected against multi-threaded accesses, and you must be careful about calling the right method; it won't help much calling AcquireReaderLock() when you intend to write to the variable you are trying to protect. :)

      Luc Pattyn [Forum Guidelines] [My Articles]


      I use ListBoxes for line-oriented text (not TextBoxes), and PictureBoxes for pictures (not drawings).


      1 Reply Last reply
      0
      • T the_jat

        Hi everyone! I wanted to know how the ReaderWriterLock determines what is the "resource" in the code on which it has to accquire the reader lock or the writer lock, or how exactly does these locks work(internally). The MSDN article protects an static integer, but doesn't seem to specify how, as after acquiring a reader lock, writes can be done as in the following code:

        ReaderWriterLock rw = new ReaderWriterLock();
        int counter = 0;
        try
        {
        rw.AcquireReaderLock(100);
        try
        {
        Interlocked.Increment(ref counter);
        }
        finally
        {
        rw.ReleaseLock();
        }
        }
        catch (ApplicationException)
        {
        Console.WriteLine("Failed");
        }
        Console.WriteLine(counter);

        here we are acquiring an reader lock for 100ms, but writing to the data. Confused :doh:

        J Offline
        J Offline
        Jon Rista
        wrote on last edited by
        #3

        Your blending two different kinds of locking. If you use Interlocked, all operations performed with it ARE thread-safe...you don't need to bother with a ReaderWriterLock. Interlocked is the lightest weight thread sync feature available in .NET, and it should be used in favor of any other locking when possible. I would recommend dropping the RWL and just keep the Interlocked.

        1 Reply Last reply
        0
        • T the_jat

          Hi everyone! I wanted to know how the ReaderWriterLock determines what is the "resource" in the code on which it has to accquire the reader lock or the writer lock, or how exactly does these locks work(internally). The MSDN article protects an static integer, but doesn't seem to specify how, as after acquiring a reader lock, writes can be done as in the following code:

          ReaderWriterLock rw = new ReaderWriterLock();
          int counter = 0;
          try
          {
          rw.AcquireReaderLock(100);
          try
          {
          Interlocked.Increment(ref counter);
          }
          finally
          {
          rw.ReleaseLock();
          }
          }
          catch (ApplicationException)
          {
          Console.WriteLine("Failed");
          }
          Console.WriteLine(counter);

          here we are acquiring an reader lock for 100ms, but writing to the data. Confused :doh:

          M Offline
          M Offline
          Mark Salsbery
          wrote on last edited by
          #4

          In addition to the other replies... Also keep in mind that the two methods of locking have different uses. A ReaderWriterLock is for synchronizing access to a resource that is read often but written to infrequently. That can give you better performance than locking on every read and write. Mark

          Mark Salsbery Microsoft MVP - Visual C++ :java:

          1 Reply Last reply
          0
          Reply
          • Reply as topic
          Log in to reply
          • Oldest to Newest
          • Newest to Oldest
          • Most Votes


          • Login

          • Don't have an account? Register

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • World
          • Users
          • Groups