472,142 Members | 1,325 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,142 software developers and data experts.

C# synchronized methods?

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.
Nov 17 '05 #1
8 79453
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.

Nov 17 '05 #2
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" wrote:
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.

Nov 17 '05 #3
"Richard Blewett [DevelopMentor]" <ri******@NOSPAMdevelop.com> wrote in
news:OD**************@TK2MSFTNGP09.phx.gbl:
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.
Nov 17 '05 #4
=?Utf-8?B?QnJpYW4gRGVsYWh1bnR5?=
<Br************@discussions.microsoft.com> wrote in
news:E4**********************************@microsof t.com:
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.
Nov 17 '05 #5
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/iangblo...retimedlocking

Regards

Richard Blewett
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk
=?Utf-8?B?QnJpYW4gRGVsYWh1bnR5?=
<Br************@discussions.microsoft.com> wrote in
news:E4**********************************@microsof t.com:
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.

Nov 17 '05 #6
"Richard Blewett [DevelopMentor]" <ri******@NOSPAMdevelop.com> wrote in
news:eM**************@tk2msftngp13.phx.gbl:
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/iangblo...retimedlocking

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. ;)
Nov 17 '05 #7
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" <Br************@discussions.microsoft.com> escribió en el
mensaje news:E4**********************************@microsof t.com...
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" wrote:
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.

Nov 17 '05 #8
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

"Richard Blewett [DevelopMentor]" <ri******@NOSPAMdevelop.com> wrote in
news:eM**************@tk2msftngp13.phx.gbl:
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/iangblo...retimedlocking

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]
Nov 17 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Frank | last post: by
5 posts views Thread by Max Ischenko | last post: by
3 posts views Thread by Keith Veleba | last post: by
6 posts views Thread by rmunson8 | last post: by
1 post views Thread by KK | last post: by
28 posts views Thread by Michael Primeaux | last post: by
1 post views Thread by fniles | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.