C# synchronized methods?

  • Thread starter Thread starter ASP.Net programmer
  • Start date Start date
A

ASP.Net programmer

Hi,

I have a few methods in a class that I want to synchronize (make sure they
can't be used at the same time by multiple threads).

As a Java programmer I just do this:
public synchronized void methodName() {...}

What is the C# alternative for this?

TIA.
 
You can decorate the method with the MethodImpl attribute

[MethodImpl(MethodImplOptions.Synchronized)]

However, you can normally achieve better results with explicit acquisition on monitors only around the pieces of code that are work with shared state. Better as in less contention -> better throughput.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Hi,

I have a few methods in a class that I want to synchronize (make sure they
can't be used at the same time by multiple threads).

As a Java programmer I just do this:
public synchronized void methodName() {...}

What is the C# alternative for this?

TIA.
 
Just wrap the entire content of your method in a lock statement.

E.g.

public class MyClass
{
public void MyMethod()
{
lock(typeof(MyClass))
{
// contents of method
}
}
}

Alternatively, you could do this:

[MethodImpl(MethodImplOptions.Synchronized)]
public void MyMethod()
{
// Contents of method
}

Both are not exactly the same and the second one is more like the
synchronized keyword in Java but in general people use locks in C# as it
gives you more fine grained control.

Hope this helps.
 
You can decorate the method with the MethodImpl attribute

[MethodImpl(MethodImplOptions.Synchronized)]

However, you can normally achieve better results with explicit
acquisition on monitors only around the pieces of code that are work
with shared state. Better as in less contention -> better throughput.

Regards

Richard Blewett - DevelopMentor

Thank you Richard. I think I'll use the lock code that Brian posted, only
because I am more comfortable with that and it is immediately obvious what
it does.

Thanks for the quick reply.
 
=?Utf-8?B?QnJpYW4gRGVsYWh1bnR5?=
Just wrap the entire content of your method in a lock statement.

E.g.

public class MyClass
{
public void MyMethod()
{
lock(typeof(MyClass))
{
// contents of method
}
}
}

Alternatively, you could do this:

[MethodImpl(MethodImplOptions.Synchronized)]
public void MyMethod()
{
// Contents of method
}

Both are not exactly the same and the second one is more like the
synchronized keyword in Java but in general people use locks in C# as
it gives you more fine grained control.

Hope this helps.

It sure helps!

I'll use the lock code, because that looks better IMO and I'll know what
I wrote in a few months from now. ;)

Thanks for the quick reply.
 
Be careful with the lock keyword.

It doesn't take a timeout - infinite waits and multithreading are a nasty source of deadlocks. It would be better to use Ian Griffiths' TimedLock

http://www.interact-sw.co.uk/iangblog/2004/04/26/yetmoretimedlocking

Regards

Richard Blewett
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk


=?Utf-8?B?QnJpYW4gRGVsYWh1bnR5?=
Just wrap the entire content of your method in a lock statement.

E.g.

public class MyClass
{
public void MyMethod()
{
lock(typeof(MyClass))
{
// contents of method
}
}
}

Alternatively, you could do this:

[MethodImpl(MethodImplOptions.Synchronized)]
public void MyMethod()
{
// Contents of method
}

Both are not exactly the same and the second one is more like the
synchronized keyword in Java but in general people use locks in C# as
it gives you more fine grained control.

Hope this helps.

It sure helps!

I'll use the lock code, because that looks better IMO and I'll know what
I wrote in a few months from now. ;)

Thanks for the quick reply.
 
Be careful with the lock keyword.

It doesn't take a timeout - infinite waits and multithreading are a
nasty source of deadlocks. It would be better to use Ian Griffiths'
TimedLock

http://www.interact-sw.co.uk/iangblog/2004/04/26/yetmoretimedlocking

Regards

Richard Blewett
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Hi Richard,

I use similair code like this in the lock blocks:

dsWSCompany1.Clear();
daWSCompany.SelectCommand.CommandText = "select * from
company where name like '" + companyName + "'" + " order by name";
daWSCompany.Fill(dsWSCompany1);
return dsWSCompany1;

It's for an ASP.Net project. It's not very likely that this takes too
much time and the select command itself will time-out anyway.

Thanks for the warning, though. ;)
 
Hi, Brian!

The synchronized keyword in Java can be used not only as a method
'attribute', but also as a statement:

synchronized (object) { statement; }

I used to think the creators of C# decided to retain in the language only
this synchronization construct as more 'general'. I had not seen before the
use of the MethodImplOptions.Synchronized option.

Regards - Octavio

Brian Delahunty said:
Just wrap the entire content of your method in a lock statement.

E.g.

public class MyClass
{
public void MyMethod()
{
lock(typeof(MyClass))
{
// contents of method
}
}
}

Alternatively, you could do this:

[MethodImpl(MethodImplOptions.Synchronized)]
public void MyMethod()
{
// Contents of method
}

Both are not exactly the same and the second one is more like the
synchronized keyword in Java but in general people use locks in C# as it
gives you more fine grained control.

Hope this helps.

--
Brian Delahunty
Ireland

http://briandela.com/blog


ASP.Net programmer said:
Hi,

I have a few methods in a class that I want to synchronize (make sure
they
can't be used at the same time by multiple threads).

As a Java programmer I just do this:
public synchronized void methodName() {...}

What is the C# alternative for this?

TIA.
 
Thats not the issue I'm talking about.

void Method1()
{
lock(foo)
{
lock(bar)
{
// do something requiring foo and bar
}
}
}

void Method2()
{
lock(bar)
{
lock(foo)
{
// do something requiring foo and bar
}
}
}

If these two methods execute concurrently you have a reasonable chance of deadlock (a deadly embrace). The problem is the two threads will just halt and never continue so you are in an unrecoverable position that can't even supply any diagnostics. If you had a timeout in those lock statements you have the ability to realise that you cannot acquire a lock for some reason and that you have a deadlock situation. These can then be be logged and so diagnosed later. In some situation you can simply retry the operation and it succeeds as the other thread will have finished.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Be careful with the lock keyword.

It doesn't take a timeout - infinite waits and multithreading are a
nasty source of deadlocks. It would be better to use Ian Griffiths'
TimedLock

http://www.interact-sw.co.uk/iangblog/2004/04/26/yetmoretimedlocking

Regards

Richard Blewett
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Hi Richard,

I use similair code like this in the lock blocks:

dsWSCompany1.Clear();
daWSCompany.SelectCommand.CommandText = "select * from
company where name like '" + companyName + "'" + " order by name";
daWSCompany.Fill(dsWSCompany1);
return dsWSCompany1;

It's for an ASP.Net project. It's not very likely that this takes too
much time and the select command itself will time-out anyway.

Thanks for the warning, though. ;)

[microsoft.public.dotnet.languages.csharp]
 
Back
Top