none
Locks on Reference Types RRS feed

  • Question

  • I thought I understood what lock does but now I'm not sure. I have a windows service that launches two timers. Each timer does its own thing but one thing they both do is read/write to the same local file via StreamWriter. So if in my code for "each" timer (thread) I do something like:

    FileHelper fh = New FileHelper();
    fh.Write(fileName);
    .
    .

    The Write method inside the FileHelper class better have a "lock(obj)" surrounding the critical code that actually writes to the file? I was pretty comfortable when the class/methods were static but in this case they are reference types and have to remain that way.

    Thanks

     


    Paul Reed
    Wednesday, February 9, 2011 2:57 PM

Answers

  • Paul,

     

    If they're trying to write to the same file - you're going to have a different problem.  Two streams can't be opened to write to a file (normally) at the same time.  This is separate from locking.

     

    You may need to make your FileHelper class append to the file and close it ASAP.  The method that "appends" to the file would need to handle failures in a try/catch, and retry (after a delay?) until it succeeds.  

     

    -Reed

     


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    • Marked as answer by Paul Reed Wednesday, February 9, 2011 6:06 PM
    Wednesday, February 9, 2011 6:01 PM
    Moderator

All replies

  • Why can't you have static method in your reference type?

    And it will be better to use ReadWriteLock class in your situation

    Wednesday, February 9, 2011 5:02 PM
  •  

    The Write method inside the FileHelper class better have a "lock(obj)" surrounding the critical code that actually writes to the file? I was pretty comfortable when the class/methods were static but in this case they are reference types and have to remain that way.

     

    This is one option.  It's only important, of course, if you want to allow this to be used by multiple threads.  If you're never going to share a single "FileHelper" between two threads, then you don't have to add synchronization.

     

    If you are, however, then you may want to use locking or some other form of synchronization to prevent problems from occurring if two threads try to write simultaneously.  The easiest way to do this is to make a private "synchronization" object within the class, and lock on it inside of any methods that are using a shared resource or shared data.

     


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    Wednesday, February 9, 2011 5:19 PM
    Moderator
  • Reed,

    Thanks...in my case...each timer launches code in another object who each "new up" their own FileHelper class. FileHelper lives in a Utilities DLL. So each timer (thread) are not sharing the same reference. So, if I understand you then I don't need synchronization. Because I had an exception thrown by one of the write requests basically saying "the process cant access the file blah blah because it is being used by another process".

    Thanks


    Paul Reed
    Wednesday, February 9, 2011 5:27 PM
  • Paul,

     

    If they're trying to write to the same file - you're going to have a different problem.  Two streams can't be opened to write to a file (normally) at the same time.  This is separate from locking.

     

    You may need to make your FileHelper class append to the file and close it ASAP.  The method that "appends" to the file would need to handle failures in a try/catch, and retry (after a delay?) until it succeeds.  

     

    -Reed

     


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    • Marked as answer by Paul Reed Wednesday, February 9, 2011 6:06 PM
    Wednesday, February 9, 2011 6:01 PM
    Moderator
  • Reed,

    I think I need to make these methods static and then provide the locking mechanism of choice (as the responder suggested the ReadWriteLock perhaps). That way all objects of that type will share the same read and write methods.

    Thanks,

    Paul


    Paul Reed
    Wednesday, February 9, 2011 6:05 PM