On 9/6/2012 8:22 AM, Registered User wrote:
> On Wed, 5 Sep 2012 00:04:18 -0700 (PDT), archana <(E-Mail Removed)>
> wrote:
>> Need some suggestion on implementating locking mechanism.
>> currently i have multple asynchronous request which have one callback
>> function. In callback , i am traverssing through dictionary and adding
>> into some shared dictionary, Callback is shared accross multiple
>> thread. So to prevent more than one thread trying to add to sharred
>> dictionary i have enclosed in lock statement.
>>
>> But I am thinking of removing lock statment from entire callback and
>> adding lock statment only when looking into shared resource and adding
>> to shared resource.
>>
> In .NET 4 the System.Collections.Concurrent namespace contains several
> thread-safe data structures.
> <http://msdn.microsoft.com/en-us/library/system.collections.concurrent.aspx>
> http://msdn.microsoft.com/en-us/libr...oncurrent.aspx

Note that thread safe here is used in the traditional meaning: thread
safe for single operations.

In some multi operations scenarios explicit locking is still
necessary.

Arne

On 9/6/2012 1:48 PM, Marcel Müller wrote:
> On 06.09.2012 04:32, Arne Vajhøj wrote:
>> I don't see how that guarantees that updates are visible to
>> other treads.
>
> It doesn't, but as long as other threads do not synchronize otherwise to
> the changing thread, it makes no difference. It is just as if the other
> thread has been some more ahead in time.

The updates must be used by something - otherwise there are no reason
to do them at all.

So something should be missing them.

> And in practice it simply works, since incoherent caches are not that
> common.

"not that common" is not a good reason to write code with
concurrency bugs in.

Arne

On 9/6/2012 5:21 AM, Brian Cryer wrote:
> "Arne Vajhøj" <(E-Mail Removed)> wrote in message
> news:50480bf6$0$293$(E-Mail Removed)...
>> On 9/5/2012 5:14 AM, Brian Cryer wrote:
>>> "archana" <(E-Mail Removed)> wrote in message
>>> news:50fb66e4-bfcc-4132-b59b-(E-Mail Removed)...
>>>
>>>> But I am thinking of removing lock statment from entire callback and
>>>> adding lock statment only when looking into shared resource and adding
>>>> to shared resource.
>>>>
>>>> My query is will it cause any issue if more than one thread try to
>>>> look into dictionary and try to add same value at the same time to
>>>> dictionary.
>>>>
>>>> Can anyone please shed some light on this/
>>>>
>>>> thanks in advance.
>>>
>>> Short answer: Yes it will cause issues
>>
>> Not necessarily.
>
> I agree that there is always a chance that you'd get away with it, but I
> don't think that trusting to luck is a sensible approach because
> eventually it will break - the only question is how long it will go
> before breaking and how repeatable it is. So I think my original short
> answer was correct: "Yes it will cause issues, so keep it as it is" -
> i.e. keep locking in place.

No.

The problem is:

#But I am thinking of removing lock statment from entire callback and
#adding lock statment only when looking into shared resource and adding
#to shared resource.

So he now has code like:

rettype callback()
{
lock(somelockobject)
{
foobar();
firstsharedobject.dosomething();
barfoo();
secondsharedobject.dosomething();
foobarfoobar();
}
}

and are considering either:

rettype callback()
{
foobar();
lock(somelockobject)
{
firstsharedobject.dosomething();
barfoo();
secondsharedobject.dosomething();
}
foobarfoobar();
}

or:

rettype callback()
{
foobar();
lock(somelockobject)
{
firstsharedobject.dosomething();
}
barfoo();
lock(somelockobject)
{
secondsharedobject.dosomething();
}
foobarfoobar();
}

The first is perfectly threadsafe.

The second is perfectly thread safe in single operation perspective
(and that is unfortunately the traditional meaning of thread safe),
but not thread safe in multi operation context.

So the code may be fine.

Arne

On 06.09.12 14.22, Registered User wrote:
> In .NET 4 the System.Collections.Concurrent namespace contains several
> thread-safe data structures.
> <http://msdn.microsoft.com/en-us/library/system.collections.concurrent.aspx>

Well, these are AFAIR mainly lock-free data structures. This might be
state of the art, but especially the ConcurrentDictionary is not that
trivial to implement that way. And in fact it is slower than an ordinary
dictionary with an ordinary lock in most cases. Unfortunately I did not
bookmark the link to the article where this was tested.
Note that this applies to .NET 4.0. The .NET 4.5 implementations have
been improved.


Marcel

On 9/9/2012 3:15 AM, Marcel Müller wrote:
> On 06.09.12 14.22, Registered User wrote:
>> In .NET 4 the System.Collections.Concurrent namespace contains several
>> thread-safe data structures.
>> <http://msdn.microsoft.com/en-us/library/system.collections.concurrent.aspx>
>
> Well, these are AFAIR mainly lock-free data structures. This might be
> state of the art, but especially the ConcurrentDictionary is not that
> trivial to implement that way. And in fact it is slower than an ordinary
> dictionary with an ordinary lock in most cases. Unfortunately I did not
> bookmark the link to the article where this was tested.
> Note that this applies to .NET 4.0. The .NET 4.5 implementations have
> been improved.

And it is still single operation integrity.

Often multi operation integrity is what one needs.

Constructs like:

if(mylist.Count > 0)
{
X o = mylist[0];
mylist.RemoveAt(0);
...
}

and:

mydict[key] = mydict[key] + 1;

Arne

On 10.09.2012 03:41, Arne Vajhøj wrote:
[ConcurrentHashMap]
> And it is still single operation integrity.
>
> Often multi operation integrity is what one needs.
>
> Constructs like:
>
> if(mylist.Count > 0)
> {
> X o = mylist[0];
> mylist.RemoveAt(0);

You wont get that happy with RemoveAt in a hash table. ;-)

> ...
> }
>
> and:
>
> mydict[key] = mydict[key] + 1;

Well, the interface is a bit more sophisticated:

X o;
if (mylist.TryRemove(key, out o))
{ ...
}

mylist.AddOrUpdate(key, k => throw new KeyNotFoundException(), (k,v) =>
v+1);


Marcel