lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicholas Paldino [.NET/C MVP#]" <casper...@caspershouse.com>
Subject Re: [Lucene.Net] 2.9.4
Date Fri, 23 Sep 2011 03:58:42 GMT
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