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 > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > >