Alright, I've really dug into changing a lot of the non CLS stuff - but I don't
think it's worth doing for 2.9.4. Please see
https://issues.apache.org/jira/browse/LUCENENET-446 for more details.
Unless anyone disagrees and still thinks we should attempt to clear the CLS
warnings - is there anything else holding us up from a 2.9.4 release at this
point?
~P
----------------------------------------
> From: casper...@caspershouse.com
> To: geobmx...@hotmail.com; lucene-net-dev@lucene.apache.org
> Date: Fri, 23 Sep 2011 06:33:03 -0700
> Subject: RE: [Lucene.Net] 2.9.4
>
> NP
>
> ----------------------------------------
>
> From: "Prescott Nasser" <geobmx...@hotmail.com>
>
> Sent: Friday, September 23, 2011 9:31 AM
>
> To: lucene-net-dev@lucene.apache.org, casper...@caspershouse.com
>
> Subject: RE: [Lucene.Net] 2.9.4
>
>
> That helps thanks. No Jira although I will put one in.
>
>
> Sent from my Windows Phone
>
>
> -----Original Message-----
>
> From: casper...@caspershouse.com
>
> Sent: Friday, September 23, 2011 6:05 AM
>
> To: lucene-net-dev@lucene.apache.org
>
> Subject: RE: [Lucene.Net] 2.9.4
>
>
> 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
>
>
> > >>>>>>
>
>
> > >>>>>>
>
>
> > >>>>>
>
>
> > >>>>
>
>
> > >>>
>
>
> >
>
>
> >
>
