PC Review


Reply
Thread Tools Rate Thread

Asynchronous call implementation

 
 
Arne Vajh°j
Guest
Posts: n/a
 
      7th Sep 2012
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


 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      7th Sep 2012
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


 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      7th Sep 2012
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:(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

 
Reply With Quote
 
Marcel MŘller
Guest
Posts: n/a
 
      9th Sep 2012
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
 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      10th Sep 2012
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

 
Reply With Quote
 
Marcel MŘller
Guest
Posts: n/a
 
      11th Sep 2012
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
 
Reply With Quote
 
 
 
Reply

Thread Tools
Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Asynchronous server implementation using either byte array or memory stream. Roger Down Microsoft Dot NET Framework 3 7th May 2007 07:08 PM
Help with Asynchronous implementation of my method =?Utf-8?B?ZGJhMTIz?= Microsoft Dot NET 0 26th Jul 2006 10:46 PM
True asynchronous HttpWebRequest implementation with abort and timeout Alexander Microsoft Dot NET Framework 0 20th Jul 2005 09:30 PM
True asynchronous HttpWebRequest implementation with abort and timeout Daniel Microsoft Dot NET Framework 1 20th Jul 2005 06:36 PM
Warning 1684 CA2214 : Microsoft.Usage : 'RandomShade..ctor(Int32, Int32, Int32, Int32, Int32)' contains a call chain that results in a call to a virtual method defined by the class. Review the following call stack for unintended consequences: steve bull Microsoft C# .NET 4 7th Jul 2005 05:54 PM


Features
 

Advertising
 

Newsgroups
 


All times are GMT +1. The time now is 04:14 AM.