use of lock keyword in single threaded applications.

[Guest]

Hi,

Once I wrote a singlethreaded program containing a somewhat large tree
structured set of objects. A treeview was assigned this structure and it was
possible to drag and drop objects - i.e. reorganize the tree structure. Each
object, tagged to a tree node, had a ref to its own userform, however, after
a drag drop operation a non-reproducable bug sometimes occured stating that
the reference was lost and an exception occured. A more .Net experienced
programmer told me that it possibly was the memory manager that was
reorganizing my objects in the memory at the same time I reorganised them and
that I should try to use the lock keyword while I reorganised the tree
structure. Could he be right?

And if yes...
I've searched the net for information on this but all articles I've found
revolves around multithreaded applications. Do you know any articles that
covers this use of the lock keyword - I would like to learn to do it right?

Best regards Jesper, Denmark.

 

[Richard Blewett [DevelopMentor]]

Jesper,

I'd advise putting your fingers in your ears whenever this "more .Net experienced programmer" says anything.

If there is only one thread in this application he is talking complete rubbish. Even if there is more than one thread he is still talking rubbish with respect to the garbage collector moving things while your application is executing.

The Garbage collector definitely does move things around in memory, but it suspends all managed threads while it does it and patches up any references before it resumes the threads so this memory management is invisible to your application code.

The lock keyword (which is simply a C# language construct automating the use of the Monitor class) only synchronizes between your application threads not threads the runtime uses internally. If you only have one application thread then all you achieve with lock is to add overhead to your application.

Are you absolutely sure you only have one thread? There are a number of actions that can cause multiple threads to execute in your code without you explicitly creating a thread via the System.Threading.Thread class: certain use of timers; invoking delegates asynchronously; use of remoting to name a few.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Hi

Once I wrote a singlethreaded program containing a somewhat large tree
structured set of objects. A treeview was assigned this structure and it was
possible to drag and drop objects - i.e. reorganize the tree structure. Each
object, tagged to a tree node, had a ref to its own userform, however, after
a drag drop operation a non-reproducable bug sometimes occured stating that
the reference was lost and an exception occured. A more .Net experienced
programmer told me that it possibly was the memory manager that was
reorganizing my objects in the memory at the same time I reorganised them and
that I should try to use the lock keyword while I reorganised the tree
structure. Could he be right?

And if yes...
I've searched the net for information on this but all articles I've found
revolves around multithreaded applications. Do you know any articles that
covers this use of the lock keyword - I would like to learn to do it right?

Best regards Jesper, Denmark.