From lucene-net-dev-return-5568-apmail-lucene-lucene-net-dev-archive=lucene.apache.org@lucene.apache.org Sat Oct 1 23:32:00 2011 Return-Path: X-Original-To: apmail-lucene-lucene-net-dev-archive@www.apache.org Delivered-To: apmail-lucene-lucene-net-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E1C079324 for ; Sat, 1 Oct 2011 23:32:00 +0000 (UTC) Received: (qmail 4911 invoked by uid 500); 1 Oct 2011 23:32:00 -0000 Delivered-To: apmail-lucene-lucene-net-dev-archive@lucene.apache.org Received: (qmail 4875 invoked by uid 500); 1 Oct 2011 23:32:00 -0000 Mailing-List: contact lucene-net-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: lucene-net-dev@lucene.apache.org Delivered-To: mailing list lucene-net-dev@lucene.apache.org Received: (qmail 4866 invoked by uid 99); 1 Oct 2011 23:32:00 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 01 Oct 2011 23:32:00 +0000 X-ASF-Spam-Status: No, hits=0.1 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of geobmx540@hotmail.com designates 65.55.34.207 as permitted sender) Received: from [65.55.34.207] (HELO col0-omc4-s5.col0.hotmail.com) (65.55.34.207) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 01 Oct 2011 23:31:53 +0000 Received: from COL109-W43 ([65.55.34.200]) by col0-omc4-s5.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 1 Oct 2011 16:31:32 -0700 Message-ID: X-Originating-IP: [76.14.37.244] From: Prescott Nasser To: Date: Sat, 1 Oct 2011 16:31:32 -0700 Importance: Normal In-Reply-To: <3dda0ea2$2fd844e8$7753c5ef$@com> References: <3dda0ea2$2fd844e8$7753c5ef$@com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Oct 2011 23:31:32.0405 (UTC) FILETIME=[4095EE50:01CC8092] X-Virus-Checked: Checked by ClamAV on apache.org Subject: RE: [Lucene.Net] 2.9.4 Alright=2C 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.o= rg/jira/browse/LUCENENET-446 for more details. =20 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 th= is point? =20 ~P ---------------------------------------- > From: casperone@caspershouse.com > To: geobmx540@hotmail.com=3B lucene-net-dev@lucene.apache.org > Date: Fri=2C 23 Sep 2011 06:33:03 -0700 > Subject: RE: [Lucene.Net] 2.9.4 > > NP > > ---------------------------------------- > > From: "Prescott Nasser" > > Sent: Friday=2C September 23=2C 2011 9:31 AM > > To: lucene-net-dev@lucene.apache.org=2C casperone@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: casperOne@caspershouse.com > > Sent: Friday=2C September 23=2C 2011 6:05 AM > > To: lucene-net-dev@lucene.apache.org > > Subject: RE: [Lucene.Net] 2.9.4 > > > Prescott=2C > > > You can do one of two things: > > > - Remove the volatile keyword=2C but keep the lock statement around the > > access to the field > > > - Remove the lock=2C and add the volatile keyword to the field > > > This will allow you to assign to the _infoStream variable (read/write) an= d > > be sure to have the most up-to-date value in the variable=2C 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=2C if you > > assign a new person instance to p=2C you can do so without using a lock > > statement and guarantee that the reads/writes from p will be atomic. > > > However=2C any calls you make to p are not protected=2C not because of > > volatile. Volatile will *never* be able to protect calls=2C it only > protects > > variables. > > > Lock=2C on the other hand=2C can protect calls=2C 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=3B when > applied > > to multiple statements=2C 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=2C for example) then > the > > previous values don't roll back or anything. > > > Because atomicity with a variable assignment is mutually exclusive around > > *one* operation=2C there's no chance of corruption. > > > Let me know if you want further clarification. > > > Additionally=2C if you have a specific patch/issue in JIRA you want me to > > look at=2C let me know=2C I'll let you know if the solution is right from= a > > thread-safety point of view. > > > - Nick > > > ---------------------------------------- > > > From: "Prescott Nasser" > > > Sent: Friday=2C September 23=2C 2011 1:17 AM > > > To: lucene-net-dev@lucene.apache.org > > > Subject: RE: [Lucene.Net] 2.9.4 > > > I see=2C so you're essentially saying=2C I can simply remove the volatile > > keyword in this case=2C 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 i= s > > called on the object itself - suppose: > > > public person { > > > _name =3D "Me" > > > public changeName(string n) > > > { > > > _name =3D n=3B > > > } > > > } > > > If one were to write > > > public volatile person p =3D new person()=3B > > > p.changeName("You")=3B > > > 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 =3D new person()=3B > > > p =3D new person(): > > > x =3D p=3B > > > p =3D new person()=3B > > > Here=2C I wouldn't need the volatile keyword becuase those are merely rea= ds > > and wrights? > > > ---------------------------------------- > > > > CC: lucene-net-dev@lucene.apache.org > > > > From: casperOne@caspershouse.com > > > > Date: Thu=2C 22 Sep 2011 23:58:42 -0400 > > > > To: lucene-net-dev@lucene.apache.org > > > > Subject: Re: [Lucene.Net] 2.9.4 > > > > > > > > Prescott=2C > > > > > > > > You really don't need to do that=3B reads and writes of reference field= s > > 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=2C then the lock statement is appropriate=2C but in t= his > > case it's not. > > > > > > > > The volatile keyword in this case (assuming no lock) would absolutely b= e > > needed to guarantee that the variable has the most up-to-date value at th= e > > time of access=3B using lock does this for you and makes volatile > > unnecessary. > > > > > > > > - Nick > > > > > > > > > > > > > > > > On Sep 22=2C 2011=2C at 11:14 PM=2C Prescott Nasser > > wrote: > > > > > > > > > > > > > > Before I go replacing all the volatile fields I wanted to run this > past > > the list: > > > > > > > > > > > > > > > > > > > > private System.IO.StreamWriter infoStream=3B > > > > > > > > > > > > > > > into > > > > > > > > > > > > > > > > > > > > private object o =3D new object()=3B > > > > > private System.IO.StreamWriter _infoStream=3B > > > > > private System.IO.StreamWriter infoStream > > > > > { > > > > > get > > > > > { > > > > > lock (o) > > > > > { > > > > > return _infoStream=3B > > > > > } > > > > > } > > > > > set > > > > > { > > > > > lock (o) > > > > > { > > > > > _infoStream =3D value=3B > > > > > } > > > > > } > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sorry=2C I don't normally deal with locks.. > > > > > > > > > > > > > > > > > > > > Thanks for any guidance > > > > > > > > > > > > > > > > > > > > ~P > > > > > > > > > >> > > > > >> @Prescott=2C > > > > >> 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 wrap= s > > access > > > > >> to that field? > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> On Wed=2C Sep 21=2C 2011 at 1:36 PM=2C Troy Howard > > 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=2C > > > > >>> Troy > > > > >>> > > > > >>> On Wed=2C Sep 21=2C 2011 at 10:15 AM=2C Michael Herndon > > > > >>> wrote: > > > > >>>> if thats the case=2C then well need conditional statements for > > including > > > > >>>> ThreadLocal > > > > >>>> > > > > >>>> On Wed=2C Sep 21=2C 2011 at 12:47 PM=2C Prescott Nasser > > > > > >>>> wrote: > > > > >>>> > > > > >>>>> I thought this was after 2.9.4 > > > > >>>>> > > > > >>>>> Sent from my Windows Phone > > > > >>>>> > > > > >>>>> -----Original Message----- > > > > >>>>> From: Michael Herndon > > > > >>>>> Sent: Wednesday=2C September 21=2C 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=2C > > > > >>>>> > > > > >>>>> 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=2C Agreed. > > > > >>>>> > > > > >>>>> On Wed=2C Sep 21=2C 2011 at 8:08 AM=2C Robert Jordan > > wrote: > > > > >>>>> > > > > >>>>>> On 20.09.2011 23:48=2C 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=2C 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/c5218bca56c19b3407648224781= eec > > > 7316994a39 > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> https://github.com/robert-j/**lucene.net/commit/** > > > > >>>>>> 50bad187655d59968d51d472b57c2a**40e201d663< > > > > >>>>> > > > > >>> > > https://github.com/robert-j/lucene.net/commit/50bad187655d59968d51d472b57= c2a > > > 40e201d663 > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Also=2C 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/23ea6f52362fc7dbce48fd012cea1= 29a > > > 7350c73c > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Did we agree about abandoning .NET <=3D 3.5? > > > > >>>>>> > > > > >>>>>> Robert > > > > >>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>> > > > > >>> > > > > > > > > > =