atomic operation

[Lloyd Dupont]

I wonder wether or not
DateTime t = DateTime.Now;
is an atomic operation ?

I have an instance variable which is a DateTime (a structure !) and many
thread at a time could write its value.
should I put a lock around that ?

I am afraid I will have something with half a given date and an other one
..... (DateTime being potentialy bigger than a register)

 

[Alvin Bruney [MVP]]

yes

 

[Lloyd Dupont]

thanks.

yes

--
Regards,
Alvin Bruney
[ASP.NET MVP http://mvp.support.microsoft.com/default.aspx]
Got tidbits? Get it here... http://tinyurl.com/27cok

I wonder wether or not
DateTime t = DateTime.Now;
is an atomic operation ?

I have an instance variable which is a DateTime (a structure !) and many
thread at a time could write its value.
should I put a lock around that ?

I am afraid I will have something with half a given date and an other one
.... (DateTime being potentialy bigger than a register)

 

[Jon Skeet [C# MVP]]

I wonder wether or not
DateTime t = DateTime.Now;
is an atomic operation ?

I have an instance variable which is a DateTime (a structure !) and many
thread at a time could write its value.
should I put a lock around that ?

I am afraid I will have something with half a given date and an other one
.... (DateTime being potentialy bigger than a register)

You should put a lock around it for reasons other than atomicity - if
you write it in one thread and read it in another, there's no guarantee
that the reading thread will see the most recently written value unless
you either:

1) Make it volatile
2) Use a lock (round both reading and writing)
3) Use explicit memory barrier calls

 

[Lloyd Dupont]

thanks Jon, you gives good insight.

hmm... however on the purely syntaxic point of view I'm afraid you're wrong.

I greatly doubt a lock will solve this volatility problem, however, what am
I seeing ?
a 'volatile' keyword in the list of C# keyword.

what a wonderful opportunity to use it, and thanks for reminding me

and about this explicit memory barrier, what are they ? never heard of them
(unfortunately)

 

[Jon Skeet [C# MVP]]

thanks Jon, you gives good insight.

hmm... however on the purely syntaxic point of view I'm afraid you're wrong.

In what way?

I greatly doubt a lock will solve this volatility problem

Why do you doubt it? The CLR spec guarantees that acquiring a lock
implicitly performs a volatile read, and releasing a lock implicitly
performs a volatile write. You therefore won't see any "cached" values.

however, what am I seeing ?
a 'volatile' keyword in the list of C# keyword.

what a wonderful opportunity to use it, and thanks for reminding me

I predict you will see error CS0677:
"a volatile filed cannot be of type 'System.DateTime'".

and about this explicit memory barrier, what are they ? never heard of them
(unfortunately)

See Thread.MemoryBarrier.

 

[Jon Skeet [C# MVP]]

Going back to the original post in this thread...

I wonder wether or not
DateTime t = DateTime.Now;
is an atomic operation ?

It might be. It might not be. The spec only states:

<quote>
A conforming CLI shall guarantee that read and write access to properly
aligned memory locations no larger than the native word size (the size
of type native int) is atomic (see clause 12.6.2). Atomic writes shall
alter no bits other than those written. Unless explicit layout control
(see Partition II (Controlling Instance Layout)) is used to alter the
default behavior, data elements no larger than the natural word size
(the size of a native int) shall be properly aligned. Object references
shall be treated as though they are stored in the native word size.
</quote>

I believe that DateTime is backed by a long - so the write in this case
won't necessarily be atomic. It may well be in the current
implementation, but you shouldn't rely on it.

As I said later though, this is pretty much incidental, as you need to
do other work to get threadsafe access anyway, and the simplest way
(using a lock) makes atomicity irrelevant here.

 

[Lloyd Dupont]

thanks Jon, you were really heplful.


--
ihookdb
Get your data mobile
http://www.ihookdb.com