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/c5218bca56c19b3407648224781eec7316994a39
> >>>>>>
> >>>>>>
> >>>>>> https://github.com/robert-j/**lucene.net/commit/**
> >>>>>> 50bad187655d59968d51d472b57c2a**40e201d663<
> >>>>>
> >>> https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57c2a40e201d663
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 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/23ea6f52362fc7dbce48fd012cea129a7350c73c
> >>>>>>
> >>>>>>
> >>>>>> Did we agree about abandoning .NET <= 3.5?
> >>>>>>
> >>>>>> Robert
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
>
>
