Prescott,
You can do one of two things:
- Remove the volatile keyword, but keep the lock statement around the
access to the field
- Remove the lock, and add the volatile keyword to the field
This will allow you to assign to the _infoStream variable (read/write) and
be sure to have the most up-to-date value in the variable, as well as
guarantee atomic reads/writes to that variable.
Your example is incorrect. The volatile on "p" only guarantees that
reads/writes will be current if p is changed. In other words, if you
assign a new person instance to p, you can do so without using a lock
statement and guarantee that the reads/writes from p will be atomic.
However, any calls you make to p are not protected, not because of
volatile. Volatile will *never* be able to protect calls, it only protects
variables.
Lock, on the other hand, can protect calls, assuming that you cover all the
calls with the same lock. You can also group other operations and make
sure that synchronization occurs.
Note that a lock *only* guarantees atomicity/mutual exclusion; when applied
to multiple statements, there's no guarantee that you won't corrupt
something. If an exception is thrown inside of a lock statement (the
second line in three lines of code in the lock block, for example) then the
previous values don't roll back or anything.
Because atomicity with a variable assignment is mutually exclusive around
*one* operation, there's no chance of corruption.
Let me know if you want further clarification.
Additionally, if you have a specific patch/issue in JIRA you want me to
look at, let me know, I'll let you know if the solution is right from a
thread-safety point of view.
- Nick
----------------------------------------
From: "Prescott Nasser" <geobmx...@hotmail.com>
Sent: Friday, September 23, 2011 1:17 AM
To: lucene-net-dev@lucene.apache.org
Subject: RE: [Lucene.Net] 2.9.4
I see, so you're essentially saying, I can simply remove the volatile
keyword in this case, and it's exactly the same becuase I am only using it
for read and writes?
So the case I'd need to be more careful of is if an manipulation method is
called on the object itself - suppose:
public person {
_name = "Me"
public changeName(string n)
{
_name = n;
}
}
If one were to write
public volatile person p = new person();
p.changeName("You");
the call to the method would in this case need a lock (which volatile
gives) to gaurentee that changeName occurs before other items read or
overwrite variable p?
but a straight read or write won't matter:
p = new person();
p = new person():
x = p;
p = new person();
Here, I wouldn't need the volatile keyword becuase those are merely reads
and wrights?
----------------------------------------
> CC: lucene-net-dev@lucene.apache.org
> From: casper...@caspershouse.com
> Date: Thu, 22 Sep 2011 23:58:42 -0400
> To: lucene-net-dev@lucene.apache.org
> Subject: Re: [Lucene.Net] 2.9.4
>
> Prescott,
>
> You really don't need to do that; reads and writes of reference fields
are guaranteed to be atomic as per section 5.5 of the C# Language
Specufication (Atomicity of variable references)
>
> If you were doing other operations beyond the read and write that you
wanted to be atomic, then the lock statement is appropriate, but in this
case it's not.
>
> The volatile keyword in this case (assuming no lock) would absolutely be
needed to guarantee that the variable has the most up-to-date value at the
time of access; using lock does this for you and makes volatile
unnecessary.
>
> - Nick
>
>
>
> On Sep 22, 2011, at 11:14 PM, Prescott Nasser <geobmx...@hotmail.com>
wrote:
>
> >
> > Before I go replacing all the volatile fields I wanted to run this past
the list:
> >
> >
> >
> > private System.IO.StreamWriter infoStream;
> >
> >
> > into
> >
> >
> >
> > private object o = new object();
> > private System.IO.StreamWriter _infoStream;
> > private System.IO.StreamWriter infoStream
> > {
> > get
> > {
> > lock (o)
> > {
> > return _infoStream;
> > }
> > }
> > set
> > {
> > lock (o)
> > {
> > _infoStream = value;
> > }
> > }
> > }
> >
> >
> >
> >
> >
> > Sorry, I don't normally deal with locks..
> >
> >
> >
> > Thanks for any guidance
> >
> >
> >
> > ~P
> >
> >>
> >> @Prescott,
> >> Can the volatile fields be wrapped in a lock statement and code that
access
> >> those fields with replaced with call to a property /method that wraps
access
> >> to that field?
> >>
> >>
> >>
> >>
> >> On Wed, Sep 21, 2011 at 1:36 PM, Troy Howard <thowar...@gmail.com>
wrote:
> >>
> >>> I thought it was:
> >>>
> >>> 2.9.2 and before are 2.0 compatible
> >>> 2.9.4 and before are 3.5 compatible
> >>> After 2.9.4 are 4.0 compatible
> >>>
> >>> Thanks,
> >>> Troy
> >>>
> >>> On Wed, Sep 21, 2011 at 10:15 AM, Michael Herndon
> >>> <mhern...@wickedsoftware.net> wrote:
> >>>> if thats the case, then well need conditional statements for
including
> >>>> ThreadLocal<T>
> >>>>
> >>>> On Wed, Sep 21, 2011 at 12:47 PM, Prescott Nasser
<geobmx...@hotmail.com
> >>>> wrote:
> >>>>
> >>>>> I thought this was after 2.9.4
> >>>>>
> >>>>> Sent from my Windows Phone
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Michael Herndon
> >>>>> Sent: Wednesday, September 21, 2011 8:30 AM
> >>>>> To: lucene-net-dev@lucene.apache.org
> >>>>> Cc: lucene-net-...@incubator.apache.org
> >>>>> Subject: Re: [Lucene.Net] 2.9.4
> >>>>>
> >>>>> @Robert,
> >>>>>
> >>>>> I believe the overwhelming consensus on the mailing list vote was
to
> >>> move
> >>>>> to
> >>>>> .NET 4.0 and drop support for previous versions.
> >>>>>
> >>>>> I'll take care of build scripts issue while they being refactored
into
> >>>>> smaller chunks this week.
> >>>>>
> >>>>> @Troy, Agreed.
> >>>>>
> >>>>> On Wed, Sep 21, 2011 at 8:08 AM, Robert Jordan <robe...@gmx.net>
wrote:
> >>>>>
> >>>>>> On 20.09.2011 23:48, Prescott Nasser wrote:
> >>>>>>
> >>>>>>> Hey all seems like we are set with 2.9.4? Feedback has been
positive
> >>> and
> >>>>>>> its been quiet. Do we feel ready to vote for a new release?
> >>>>>>>
> >>>>>>
> >>>>>> I don't know if the build infrastructure is part of the
> >>>>>> release. If yes, then there is an open issue:
> >>>>>>
> >>>>>> Contrib doesn't build right now because there
> >>>>>> are some assembly name mismatches between certain *.csproj
> >>>>>> files and build/scripts/contrib.targets.
> >>>>>>
> >>>>>> The following patches should fix the issue:
> >>>>>>
> >>>>>> https://github.com/robert-j/**lucene.net/commit/**
> >>>>>> c5218bca56c19b3407648224781eec**7316994a39<
> >>>>>
> >>>
https://github.com/robert-j/lucene.net/commit/c5218bca56c19b3407648224781eec
7316994a39
> >>>>>>
> >>>>>>
> >>>>>> https://github.com/robert-j/**lucene.net/commit/**
> >>>>>> 50bad187655d59968d51d472b57c2a**40e201d663<
> >>>>>
> >>>
https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a
40e201d663
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Also, the fix for [LUCENENET-358] is basically making
> >>>>>> Lucene.Net.dll a .NET 4.0-only assembly:
> >>>>>>
> >>>>>> https://github.com/apache/**lucene.net/commit/**
> >>>>>> 23ea6f52362fc7dbce48fd012cea12**9a7350c73c<
> >>>>>
> >>>
https://github.com/apache/lucene.net/commit/23ea6f52362fc7dbce48fd012cea129a
7350c73c
> >>>>>>
> >>>>>>
> >>>>>> Did we agree about abandoning .NET <= 3.5?
> >>>>>>
> >>>>>> Robert
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
>
>
