syncronized class

[gerry]

Is there any way to specify that all methods of a class should be
synchronized other than applying the
[MethodImpl(MethodImplOptions.Synchronized)] attribute for every method ?

Gerry

[Nicholas Paldino [.NET/C# MVP]]

Gerry,

No, there is not.

Also, it's not exactly good practice to use MethodImpl, as for
instances, it uses "this" for locking on access to the methods. Not only is
that not fine grained enough, but you are exposing an implementation detail
(the object you are locking on) to the outside world.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"gerry" <ge**@nospam.nospamwrote in message
news:OD**************@TK2MSFTNGP06.phx.gbl...

Is there any way to specify that all methods of a class should be
synchronized other than applying the
[MethodImpl(MethodImplOptions.Synchronized)] attribute for every method ?

Gerry

[gerry]

thanks nicholas,

actually on further thought locking on 'this' is exactly what i do want - i
want to lock any access to the entire class
does that change your answer any ?

what about static methods - what is locked in that case ?

Gerry

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.comwrote in
message news:%2****************@TK2MSFTNGP02.phx.gbl...

Gerry,

No, there is not.

Also, it's not exactly good practice to use MethodImpl, as for
instances, it uses "this" for locking on access to the methods. Not only

is

that not fine grained enough, but you are exposing an implementation

detail

(the object you are locking on) to the outside world.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"gerry" <ge**@nospam.nospamwrote in message
news:OD**************@TK2MSFTNGP06.phx.gbl...

Is there any way to specify that all methods of a class should be
synchronized other than applying the
[MethodImpl(MethodImplOptions.Synchronized)] attribute for every method

?

Gerry

[Nicholas Paldino [.NET/C# MVP]]

Gerry,

Nope, it does not. The reason you don't want to lock on this is that it
will give someone accessing your control access to the same locking
mechaism, and could starve access to your class easily.

With static methods, MethodImpl will lock on the type. Again, you don't
want to do that for the same reasons I mentioned before. What you want to
do is something like this:

class MyClass
{
private object classLock = new object();

public void DoSomething()
{
lock (classLock)
{
}
}

public void DoSomethingElse()
{
lock (classLock)
{
}
}
}

For static methods, you want a different lock:

class MyStaticClass
{
private static object classLock = new object();

public static void DoSomething()
{
lock (classLock)
{
}
}

public static void DoSomethingElse()
{
lock (classLock)
{
}
}
}
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"gerry" <ge**@nospam.nospamwrote in message
news:um**************@TK2MSFTNGP03.phx.gbl...

thanks nicholas,

actually on further thought locking on 'this' is exactly what i do want -
i
want to lock any access to the entire class
does that change your answer any ?

what about static methods - what is locked in that case ?

Gerry

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.comwrote
in
message news:%2****************@TK2MSFTNGP02.phx.gbl...

>Gerry,

No, there is not.

Also, it's not exactly good practice to use MethodImpl, as for
instances, it uses "this" for locking on access to the methods. Not only

is

>that not fine grained enough, but you are exposing an implementation

detail

>(the object you are locking on) to the outside world.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"gerry" <ge**@nospam.nospamwrote in message
news:OD**************@TK2MSFTNGP06.phx.gbl...

Is there any way to specify that all methods of a class should be
synchronized other than applying the
[MethodImpl(MethodImplOptions.Synchronized)] attribute for every method

?

>
Gerry

[gerry]

thanks again

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.comwrote in
message news:em**************@TK2MSFTNGP05.phx.gbl...

Gerry,

Nope, it does not. The reason you don't want to lock on this is that

it

will give someone accessing your control access to the same locking
mechaism, and could starve access to your class easily.

With static methods, MethodImpl will lock on the type. Again, you

don't

want to do that for the same reasons I mentioned before. What you want to
do is something like this:

class MyClass
{
private object classLock = new object();

public void DoSomething()
{
lock (classLock)
{
}
}

public void DoSomethingElse()
{
lock (classLock)
{
}
}
}

For static methods, you want a different lock:

class MyStaticClass
{
private static object classLock = new object();

public static void DoSomething()
{
lock (classLock)
{
}
}

public static void DoSomethingElse()
{
lock (classLock)
{
}
}
}
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"gerry" <ge**@nospam.nospamwrote in message
news:um**************@TK2MSFTNGP03.phx.gbl...

thanks nicholas,

actually on further thought locking on 'this' is exactly what i do

want -

i
want to lock any access to the entire class
does that change your answer any ?

what about static methods - what is locked in that case ?

Gerry

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.comwrote
in
message news:%2****************@TK2MSFTNGP02.phx.gbl...

Gerry,

No, there is not.

Also, it's not exactly good practice to use MethodImpl, as for
instances, it uses "this" for locking on access to the methods. Not

only

is

that not fine grained enough, but you are exposing an implementation

detail

(the object you are locking on) to the outside world.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"gerry" <ge**@nospam.nospamwrote in message
news:OD**************@TK2MSFTNGP06.phx.gbl...
Is there any way to specify that all methods of a class should be
synchronized other than applying the
[MethodImpl(MethodImplOptions.Synchronized)] attribute for every

method

?

Gerry

[Dave Sexton]

Hi Gerry,

You could derive from System.ComponentModel.ContextBoundObject class and apply the
System.Runtime.Remoting.Contexts.SynchronizationAt tribute
to your class. This method provides thread-safety for all public members without any explicit locking in code (I'm not sure of the
locking mechanism but it might very well be "this").

However, this comes with a price since it uses the remoting framework internals to intercept all calls to your class and transform
them into messages. If you need a well-performing class then this method might not be your best choice, but if your class is
designed for remoting or you can just live with the performance penalty then you might want to try it out.

SynchronizationAttribute on MSDN:
http://msdn2.microsoft.com/en-us/lib...attribute.aspx

Explains ContextBoundObject and AOP in case your interested in how it works (MSDN):
http://msdn.microsoft.com/msdnmag/is...P/default.aspx

--
Dave Sexton

"gerry" <ge**@nospam.nospamwrote in message news:OD**************@TK2MSFTNGP06.phx.gbl...

Is there any way to specify that all methods of a class should be
synchronized other than applying the
[MethodImpl(MethodImplOptions.Synchronized)] attribute for every method ?

Gerry

[gerry]

thanks dave,
this looks like it might be what I am looking for ,
actually, this is a remoting situation I am dealing with - my intent is
serialize access to the remoting client.
"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

Hi Gerry,

You could derive from System.ComponentModel.ContextBoundObject class and

apply the

System.Runtime.Remoting.Contexts.SynchronizationAt tribute
to your class. This method provides thread-safety for all public members

without any explicit locking in code (I'm not sure of the

locking mechanism but it might very well be "this").

However, this comes with a price since it uses the remoting framework

internals to intercept all calls to your class and transform

them into messages. If you need a well-performing class then this method

might not be your best choice, but if your class is

designed for remoting or you can just live with the performance penalty

then you might want to try it out.

>
SynchronizationAttribute on MSDN:

http://msdn2.microsoft.com/en-us/lib...attribute.aspx

>
Explains ContextBoundObject and AOP in case your interested in how it

works (MSDN):

http://msdn.microsoft.com/msdnmag/is...P/default.aspx

--
Dave Sexton

"gerry" <ge**@nospam.nospamwrote in message

news:OD**************@TK2MSFTNGP06.phx.gbl...

Is there any way to specify that all methods of a class should be
synchronized other than applying the
[MethodImpl(MethodImplOptions.Synchronized)] attribute for every method

?

Gerry

[Dave Sexton]

Hi Gerry,

If you need to serialize an object and pass a copy to your remoting clients then you should create a custom message class that is
serializable.

ContextBoundObject derives from MarshalByRefObject so a reference will be passed to remoting clients. This means that invocations
on your ContextBoundObject will always execute on the server. If a copy was passed instead then there would be no need for
synchronization.

--
Dave Sexton

"gerry" <ge**@nospam.nospamwrote in message news:e2**************@TK2MSFTNGP02.phx.gbl...

thanks dave,
this looks like it might be what I am looking for ,
actually, this is a remoting situation I am dealing with - my intent is
serialize access to the remoting client.
"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

>Hi Gerry,

You could derive from System.ComponentModel.ContextBoundObject class and

apply the

>System.Runtime.Remoting.Contexts.SynchronizationA ttribute
to your class. This method provides thread-safety for all public members

without any explicit locking in code (I'm not sure of the

>locking mechanism but it might very well be "this").

However, this comes with a price since it uses the remoting framework

internals to intercept all calls to your class and transform

>them into messages. If you need a well-performing class then this method

might not be your best choice, but if your class is

>designed for remoting or you can just live with the performance penalty

then you might want to try it out.

>>
SynchronizationAttribute on MSDN:

http://msdn2.microsoft.com/en-us/lib...attribute.aspx

>>
Explains ContextBoundObject and AOP in case your interested in how it

works (MSDN):

>http://msdn.microsoft.com/msdnmag/is...P/default.aspx

--
Dave Sexton

"gerry" <ge**@nospam.nospamwrote in message

news:OD**************@TK2MSFTNGP06.phx.gbl...

Is there any way to specify that all methods of a class should be
synchronized other than applying the
[MethodImpl(MethodImplOptions.Synchronized)] attribute for every method

?

>
Gerry

[gerry]

what we have is multiple threads accessing the same remoting client -
multiplexing multiple converstaions through a single remoting connection.
our sync issue is on the client side not the server side.
"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:eF**************@TK2MSFTNGP02.phx.gbl...

Hi Gerry,

If you need to serialize an object and pass a copy to your remoting

clients then you should create a custom message class that is

serializable.

ContextBoundObject derives from MarshalByRefObject so a reference will be

passed to remoting clients. This means that invocations

on your ContextBoundObject will always execute on the server. If a copy

was passed instead then there would be no need for

synchronization.

--
Dave Sexton

"gerry" <ge**@nospam.nospamwrote in message

news:e2**************@TK2MSFTNGP02.phx.gbl...

thanks dave,
this looks like it might be what I am looking for ,
actually, this is a remoting situation I am dealing with - my intent is
serialize access to the remoting client.
"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

Hi Gerry,

You could derive from System.ComponentModel.ContextBoundObject class

and

apply the

System.Runtime.Remoting.Contexts.SynchronizationAt tribute
to your class. This method provides thread-safety for all public

members

without any explicit locking in code (I'm not sure of the

locking mechanism but it might very well be "this").

However, this comes with a price since it uses the remoting framework

internals to intercept all calls to your class and transform

them into messages. If you need a well-performing class then this

method

might not be your best choice, but if your class is

designed for remoting or you can just live with the performance penalty

then you might want to try it out.

>
SynchronizationAttribute on MSDN:

http://msdn2.microsoft.com/en-us/lib...attribute.aspx

>
Explains ContextBoundObject and AOP in case your interested in how it

works (MSDN):

http://msdn.microsoft.com/msdnmag/is...P/default.aspx

--
Dave Sexton

"gerry" <ge**@nospam.nospamwrote in message

news:OD**************@TK2MSFTNGP06.phx.gbl...

Is there any way to specify that all methods of a class should be
synchronized other than applying the
[MethodImpl(MethodImplOptions.Synchronized)] attribute for every

method

?

Gerry

[Dave Sexton]

Hi Gerry,

In that case, creating a class that derives from ContextBoundObject to be used as a remoting client or facade should work nicely for
you.

(In a previous post you said "serialize" access to the remoting client, and I misunderstood, since serialize was ambiguous in that
context)

GL

--
Dave Sexton

"gerry" <ge**@nospam.nospamwrote in message news:%2****************@TK2MSFTNGP05.phx.gbl...

what we have is multiple threads accessing the same remoting client -
multiplexing multiple converstaions through a single remoting connection.
our sync issue is on the client side not the server side.
"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:eF**************@TK2MSFTNGP02.phx.gbl...

>Hi Gerry,

If you need to serialize an object and pass a copy to your remoting

clients then you should create a custom message class that is

>serializable.

ContextBoundObject derives from MarshalByRefObject so a reference will be

passed to remoting clients. This means that invocations

>on your ContextBoundObject will always execute on the server. If a copy

was passed instead then there would be no need for

>synchronization.

--
Dave Sexton

"gerry" <ge**@nospam.nospamwrote in message

news:e2**************@TK2MSFTNGP02.phx.gbl...

thanks dave,
this looks like it might be what I am looking for ,
actually, this is a remoting situation I am dealing with - my intent is
serialize access to the remoting client.
"Dave Sexton" <dave@jwa[remove.this]online.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...
Hi Gerry,

You could derive from System.ComponentModel.ContextBoundObject class

and

apply the
System.Runtime.Remoting.Contexts.SynchronizationA ttribute
to your class. This method provides thread-safety for all public

members

without any explicit locking in code (I'm not sure of the
locking mechanism but it might very well be "this").

However, this comes with a price since it uses the remoting framework
internals to intercept all calls to your class and transform
them into messages. If you need a well-performing class then this

method

might not be your best choice, but if your class is
designed for remoting or you can just live with the performance penalty
then you might want to try it out.

SynchronizationAttribute on MSDN:

http://msdn2.microsoft.com/en-us/lib...attribute.aspx

>>
Explains ContextBoundObject and AOP in case your interested in how it
works (MSDN):
http://msdn.microsoft.com/msdnmag/is...P/default.aspx

--
Dave Sexton

"gerry" <ge**@nospam.nospamwrote in message
news:OD**************@TK2MSFTNGP06.phx.gbl...
Is there any way to specify that all methods of a class should be
synchronized other than applying the
[MethodImpl(MethodImplOptions.Synchronized)] attribute for every

method

?

Gerry

[Jeffrey Tan[MSFT]]

Hi Gerry,

Yes, the solution Dave provided is a correct solution per your requirement.

.Net provides the automatic synchronization for us through
System.Runtime.Remoting.Contexts.SynchronizationAt tribute. However,
components must be context-bound to take advantage of .NET automatic
synchronization. We can simple use it like this:

using System.Runtime.Remoting.Contexts;
[Synchronization]
public class MyClass : ContextBoundObject
{
public MyClass(){}
public void DoSomething(){}
//other methods and data members
}

As you can see, it is very easy to use.

The reason that the component must derive from ContextBoundObject is that
ContextBoundObject tells .NET to place all the objects in a context
(synchronization domain) and associate them with a lock, so multiple
threads can't make concurrent calls within the same synchronization domain.
Additionally, we can choose the synchronization domain while applying
SynchronizationAttribute. That is we can choose whether to create a new
synchronization domain or share the same synchronization domain as the
caller. This is based on the value we passed to SynchronizationAttribute's
constructor:
REQUIRED or REQUIRES_NEW. Normally, REQUIRED is the default value and is
what you want. However, if your application uses Class Factories pattern to
create your new component, you may want to create a new synchronization
domain for your component (using REQUIRES_NEW).

Juval Lowy has written a good article covering this automatic
synchronization in .Net:
"Sync Threads Automatically"
http://www.ftponline.com/vsm/2002_09...t/default_pf.a
spx

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.