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
  1. Home
  2. General Programming
  3. C#
  4. Do I still need to LOCK a Synchronized Queue?

Do I still need to LOCK a Synchronized Queue?

Scheduled Pinned Locked Moved C#
data-structuresquestion
5 Posts 2 Posters 0 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.
  • J Offline
    J Offline
    JoeRip
    wrote on last edited by
    #1

    if I do this:

    Queue SynchedMessageQueue = Queue.Synchronized(new Queue());

    then when I access SynchedMessageQueue, do I still need to use LOCK statements? Or is that now being handled automatically?

    W 1 Reply Last reply
    0
    • J JoeRip

      if I do this:

      Queue SynchedMessageQueue = Queue.Synchronized(new Queue());

      then when I access SynchedMessageQueue, do I still need to use LOCK statements? Or is that now being handled automatically?

      W Offline
      W Offline
      Wendelius
      wrote on last edited by
      #2

      I believe that this answers the question (from MSDN Queue.Synchronized Method[^]):

      To guarantee the thread safety of the Queue, all operations must be done through this wrapper only.

      Enumerating through a collection is intrinsically not a thread-safe procedure.
      Even when a collection is synchronized, other threads can still modify the collection, which causes the enumerator to throw an exception.
      To guarantee thread safety during enumeration,
      you can either lock the collection during the entire enumeration or catch the exceptions resulting from changes made by other threads.

      Mika

      J 1 Reply Last reply
      0
      • W Wendelius

        I believe that this answers the question (from MSDN Queue.Synchronized Method[^]):

        To guarantee the thread safety of the Queue, all operations must be done through this wrapper only.

        Enumerating through a collection is intrinsically not a thread-safe procedure.
        Even when a collection is synchronized, other threads can still modify the collection, which causes the enumerator to throw an exception.
        To guarantee thread safety during enumeration,
        you can either lock the collection during the entire enumeration or catch the exceptions resulting from changes made by other threads.

        Mika

        J Offline
        J Offline
        JoeRip
        wrote on last edited by
        #3

        Thanks. I had read this, but for some reason I cannot now remember, I questioned it. Seems pretty straightforward now!

        W 1 Reply Last reply
        0
        • J JoeRip

          Thanks. I had read this, but for some reason I cannot now remember, I questioned it. Seems pretty straightforward now!

          W Offline
          W Offline
          Wendelius
          wrote on last edited by
          #4

          You're welcome. Mika P.s. Really glad to hear that you thought about this instead if just asking :)

          J 1 Reply Last reply
          0
          • W Wendelius

            You're welcome. Mika P.s. Really glad to hear that you thought about this instead if just asking :)

            J Offline
            J Offline
            JoeRip
            wrote on last edited by
            #5

            I think what I blew off was that SPEFICICALLY, enumeration wasn't thread safe. In my mind I thought "well, if getting things from a synchronized queue isn't thread safe, what's the point?" My brain didn't translate the part where "Only the enumeration itself needs LOCK, the rest of the Queue methods do not."

            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