I have an application that uses mulitple timers. Each of the timer event
handlers manipulate a common array of data.
I'm getting Null refererance errors - should I put a lock on the array when
I change a value?
As well, should I lock the array when I only want to read a value?

FredC <Fr***@discussions.microsoft.com> wrote:
Could you post a short but complete program which demonstrates the
problem?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.

In general though, yes - you need to obtain a lock (on something, see
below) if you're going to access/change shared data.

I wouldn't lock the array, but a separate locking object. See
http://www.pobox.com/~skeet/csharp/threads/lockchoice.shtml

Which Timer class are you using?

There's System.Windows.Forms.Timer, System.Threading.Timer,
System.Timers.Timer -- and they all act very different!

System.Windows.Forms.Timer will pass WM_TIMER, causing your handler to be
called on the main thread in between user actions.  They will be serialized,
and locking does nothing if you're not pumping messages (think
Application.DoEvents) during a callback, and if you are -- deadlock with
non-recursive locks, and data corruption with recursive locks.  But if you
prevent re-entrancy by not pumping messages during the timer processing,
everything is much simpler.

The others will create background worker threads.  Locking is applicable
here.

If you're resizing the array, you must lock writes.  Otherwise locks
shouldn't be necessary.  Locking reads shouldn't be needed, although after a
resize your reads could be accessing an old copy for an extended length of
time.

Ben Voigt <rbv@nospam.nospam> wrote:

<snip>

Could you explain exactly what you mean by that?

Or they could just not "see" some of the writes at all. I tend to want
to know that the data I'm accessing is the most recent version...

A .NET array is ultimately pretty similar to a SAFEARRAY, it's a pointer to
a block of data and some accompanying size information.  If you need to grow
the array (done automatically by ArrayList or List<T>, or explicitly by
Array.Resize()), you end up with a pointer to an entirely different array,
and the runtime copies the data into the new block in the process.  But you
could end up with still having pointers to the old block in other threads.

As long as you aren't doing anything that replaces the array pointer, all
threads will be working in the same memory area.  However, the optimizing
compiler could decide to cache data in a register... you need memory fences
if "apparent" order of memory access is important.

Show quoteHide quote

Ben Voigt <rbv@nospam.nospam> wrote:
Absolutely - and I see what you mean about locking for writes now, in
that you don't want one thread writing to the old array when it's been
recreated.

Exactly. That's the point I was getting at.

How to stop an Application Pool in IIS 6.0 in c#?
Creating Events
Help with Exception handling
Large object heap...
Delegate Question: How does it know?
Creating the same class w/o duplicating?
Array.Resize question
C#/OOP Frustrations:)
convert string to string array
Interop - string from dll issue