469,610 Members | 1,494 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,610 developers. It's quick & easy.

Locking memory and multiple timers?

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?
Sep 7 '06 #1
5 4461
FredC <Fr***@discussions.microsoft.comwrote:
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?
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.
As well, should I lock the array when I only want to read a value?
I wouldn't lock the array, but a separate locking object. See
http://www.pobox.com/~skeet/csharp/t...ckchoice.shtml

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Sep 7 '06 #2

"FredC" <Fr***@discussions.microsoft.comwrote in message
news:EC**********************************@microsof t.com...
>I have an application that uses mulitple timers. Each of the timer event
handlers manipulate a common array of data.
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.
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?
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.
Sep 7 '06 #3
Ben Voigt <rb*@nospam.nospamwrote:

<snip>
As well, should I lock the array when I only want to read a value?

If you're resizing the array, you must lock writes.
Could you explain exactly what you mean by that?
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.
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...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Sep 7 '06 #4
"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...
Ben Voigt <rb*@nospam.nospamwrote:

<snip>
As well, should I lock the array when I only want to read a value?

If you're resizing the array, you must lock writes.

Could you explain exactly what you mean by that?
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.
>
>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.

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...
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.
>
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Sep 8 '06 #5
Ben Voigt <rb*@nospam.nospamwrote:
As well, should I lock the array when I only want to read a value?

If you're resizing the array, you must lock writes.
Could you explain exactly what you mean by that?

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.
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.
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...

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.
Exactly. That's the point I was getting at.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
Sep 8 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Michael Chermside | last post: by
2 posts views Thread by Sebastian Sosna | last post: by
4 posts views Thread by Miky | last post: by
6 posts views Thread by Gene Hubert | last post: by
16 posts views Thread by akantrowitz | last post: by
7 posts views Thread by Shak | last post: by
6 posts views Thread by shaanxxx | last post: by
2 posts views Thread by tim | last post: by
15 posts views Thread by Matt Brandt | last post: by
reply views Thread by devrayhaan | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.