Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Either way will work; however, I'd prefer a separate readonly, static object for synchronizing. That way its purpose is obvious and distinct for the type of lock you're performing.</p> <p>If you're locking in order to safely work with a dictionary or list, have you considered using the System.Generic.Collections.Concurrent objects?</p> <p>Also, have you considered a ReaderWriterLock? That way you can allow multiple reads, but safely lock to allow only one write at a time.</p> <p><strong>More Info</strong></p> <p>There's no difference locking against a separate object versus locking on the dictionary itself. The CLR will create or assign a SyncBlock struct and manage the lock count without regard to the object being locked. More info about that here: <a href="http://msdn.microsoft.com/en-us/magazine/cc188793.aspx" rel="nofollow">http://msdn.microsoft.com/en-us/magazine/cc188793.aspx</a></p> <p>What I think:</p> <p>A dictionary's responsibility is to store data, not synchronize threads. Use a separate object that is meant for synchronization, mark it as private readonly, and name it appropriately so that you know that the member is meant for locking.</p> <p>You and your teammates are less likely to run into confusion about who is locking what and when. If the dictionary is pulling double duty, as a synchronization object and a dictionary, then it might not be obvious to new teammates that there is locking, it's on the dictionary, and they should not create a new synchronization object.</p> <p>A new teammate might not know that the dictionary reference has dual responsibility as a synchronization object as well as a dictionary. That teammate might be tempted to pass a reference to the dictionary outside the class where it might be locked in an unexpected way that causes a deadlock. A separate synchronization object could cause your other teammates to stop and reconsider passing its reference around.</p> <p>If the member is marked as readonly and initialized before a lock is called, then you're mostly guaranteed that the member will never be null or swapped out for another reference.</p> <p>There are objects in the CLR that are meant specifically for thread synchronization. A SyncLock and Monitor.Enter are fine in most cases, but you can get much better performance by switching to a ReaderWriterLock. Not only can you allow multiple threads to read at the same time, but you can safely block all the thread to allow synchronous writes. Quick example here: <a href="http://www.codekicks.com/2008/03/readerwriterlock-cnet-systemthreading.html" rel="nofollow">http://www.codekicks.com/2008/03/readerwriterlock-cnet-systemthreading.html</a></p>
    singulars
    1. This table or related slice is empty.
    1. POlock on private static field that is in use
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USNick VanderPyle
    1. USNick VanderPyle
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThank you for your answer, but my question is not actually about List, but it is if it's save to lock on private static object that is used by class.
      singulars
      1. PO
      1. USD.P.
    2. COAh, I see. I updated my answer with more info. Basically, it's safe provided you're completely aware of when and what is locked; but having a separate object just for locking is much safer because its intent is obvious.
      singulars
      1. PO
      1. USNick VanderPyle
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload