lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Prescott Nasser <geobmx...@hotmail.com>
Subject RE: [Lucene.Net] 2.9.4
Date Fri, 23 Sep 2011 04:16:31 GMT

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: casperOne@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 <geobmx540@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 <thoward37@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
> >>> <mherndon@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 <geobmx540@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-dev@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 <robertj@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
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
>
> 		 	   		  
Mime
View raw message