|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
syncronized classIs 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,
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. -- Show quote- Nicholas Paldino [.NET/C# MVP] - mvp@spam.guard.caspershouse.com "gerry" <germ@nospam.nospam> wrote in message news:OD3t6KP2GHA.1040@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 > > 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 Show quote "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> wrote in message news:%23lWChYP2GHA.1548@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] > - mvp@spam.guard.caspershouse.com > > "gerry" <germ@nospam.nospam> wrote in message > news:OD3t6KP2GHA.1040@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,
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) { } } } -- Show quote- Nicholas Paldino [.NET/C# MVP] - mvp@spam.guard.caspershouse.com "gerry" <germ@nospam.nospam> wrote in message news:um7vQgP2GHA.4388@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]" <mvp@spam.guard.caspershouse.com> wrote > in > message news:%23lWChYP2GHA.1548@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] >> - mvp@spam.guard.caspershouse.com >> >> "gerry" <germ@nospam.nospam> wrote in message >> news:OD3t6KP2GHA.1040@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 >> > >> > >> >> > > thanks again
Show quote "Nicholas Paldino [.NET/C# MVP]" <mvp@spam.guard.caspershouse.com> wrote in message news:em6nqiP2GHA.4172@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] > - mvp@spam.guard.caspershouse.com > > > "gerry" <germ@nospam.nospam> wrote in message > news:um7vQgP2GHA.4388@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]" <mvp@spam.guard.caspershouse.com> wrote > > in > > message news:%23lWChYP2GHA.1548@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] > >> - mvp@spam.guard.caspershouse.com > >> > >> "gerry" <germ@nospam.nospam> wrote in message > >> news:OD3t6KP2GHA.1040@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 > >> > > >> > > >> > >> > > > > > > Hi Gerry,
You could derive from System.ComponentModel.ContextBoundObject class and apply the System.Runtime.Remoting.Contexts.SynchronizationAttribute 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/library/system.runtime.remoting.contexts.synchronizationattribute.aspx Explains ContextBoundObject and AOP in case your interested in how it works (MSDN): http://msdn.microsoft.com/msdnmag/issues/02/03/AOP/default.aspx -- Show quoteDave Sexton "gerry" <germ@nospam.nospam> wrote in message news:OD3t6KP2GHA.1040@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 > > 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.com> wrote in message without any explicit locking in code (I'm not sure of thenews:%23Lpq6eQ2GHA.1304@TK2MSFTNGP05.phx.gbl... > Hi Gerry, > > You could derive from System.ComponentModel.ContextBoundObject class and apply the > System.Runtime.Remoting.Contexts.SynchronizationAttribute > to your class. This method provides thread-safety for all public members > locking mechanism but it might very well be "this"). internals to intercept all calls to your class and transform> > However, this comes with a price since it uses the remoting framework > 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.> http://msdn2.microsoft.com/en-us/library/system.runtime.remoting.contexts.synchronizationattribute.aspx> SynchronizationAttribute on MSDN: > Show quote > > Explains ContextBoundObject and AOP in case your interested in how it works (MSDN): > http://msdn.microsoft.com/msdnmag/issues/02/03/AOP/default.aspx > > -- > Dave Sexton > > "gerry" <germ@nospam.nospam> wrote in message news:OD3t6KP2GHA.1040@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 > > > > > > 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. -- Show quoteDave Sexton "gerry" <germ@nospam.nospam> wrote in message news:e2OBNIZ2GHA.4976@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.com> wrote in message > news:%23Lpq6eQ2GHA.1304@TK2MSFTNGP05.phx.gbl... >> Hi Gerry, >> >> You could derive from System.ComponentModel.ContextBoundObject class and > apply the >> System.Runtime.Remoting.Contexts.SynchronizationAttribute >> 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/library/system.runtime.remoting.contexts.synchronizationattribute.aspx >> >> Explains ContextBoundObject and AOP in case your interested in how it > works (MSDN): >> http://msdn.microsoft.com/msdnmag/issues/02/03/AOP/default.aspx >> >> -- >> Dave Sexton >> >> "gerry" <germ@nospam.nospam> wrote in message > news:OD3t6KP2GHA.1040@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 >> > >> > >> >> > > 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.com> wrote in message clients then you should create a custom message class that isnews:eFCUMJd2GHA.4808@TK2MSFTNGP02.phx.gbl... > Hi Gerry, > > If you need to serialize an object and pass a copy to your remoting > serializable. passed to remoting clients. This means that invocations> > ContextBoundObject derives from MarshalByRefObject so a reference will be > on your ContextBoundObject will always execute on the server. If a copy was passed instead then there would be no need forShow quote > synchronization. http://msdn2.microsoft.com/en-us/library/system.runtime.remoting.contexts.synchronizationattribute.aspx> > -- > Dave Sexton > > "gerry" <germ@nospam.nospam> wrote in message news:e2OBNIZ2GHA.4976@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.com> wrote in message > > news:%23Lpq6eQ2GHA.1304@TK2MSFTNGP05.phx.gbl... > >> Hi Gerry, > >> > >> You could derive from System.ComponentModel.ContextBoundObject class and > > apply the > >> System.Runtime.Remoting.Contexts.SynchronizationAttribute > >> 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: > >> > > Show quote > >> > >> Explains ContextBoundObject and AOP in case your interested in how it > > works (MSDN): > >> http://msdn.microsoft.com/msdnmag/issues/02/03/AOP/default.aspx > >> > >> -- > >> Dave Sexton > >> > >> "gerry" <germ@nospam.nospam> wrote in message > > news:OD3t6KP2GHA.1040@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 > >> > > >> > > >> > >> > > > > > > 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 -- Show quoteDave Sexton "gerry" <germ@nospam.nospam> wrote in message news:%23hr1Le22GHA.3428@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.com> wrote in message > news:eFCUMJd2GHA.4808@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" <germ@nospam.nospam> wrote in message > news:e2OBNIZ2GHA.4976@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.com> wrote in message >> > news:%23Lpq6eQ2GHA.1304@TK2MSFTNGP05.phx.gbl... >> >> Hi Gerry, >> >> >> >> You could derive from System.ComponentModel.ContextBoundObject class > and >> > apply the >> >> System.Runtime.Remoting.Contexts.SynchronizationAttribute >> >> 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/library/system.runtime.remoting.contexts.synchronizationattribute.aspx >> >> >> >> Explains ContextBoundObject and AOP in case your interested in how it >> > works (MSDN): >> >> http://msdn.microsoft.com/msdnmag/issues/02/03/AOP/default.aspx >> >> >> >> -- >> >> Dave Sexton >> >> >> >> "gerry" <germ@nospam.nospam> wrote in message >> > news:OD3t6KP2GHA.1040@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 >> >> > >> >> > >> >> >> >> >> > >> > >> >> > > 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.SynchronizationAttribute. 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/magazine/columns/blackbelt/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/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights. Thanks Jeff & Dave
this info really helps. Gerry ""Jeffrey Tan[MSFT]"" <je***@online.microsoft.com> wrote in message Show quote news:gI9S9h52GHA.396@TK2MSFTNGXA01.phx.gbl... http://www.ftponline.com/vsm/2002_09/magazine/columns/blackbelt/default_pf.a> 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.SynchronizationAttribute. 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" > > spx http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif> > Hope this helps. > > Best regards, > Jeffrey Tan > Microsoft Online Community Support > ================================================== > Get notification to my posts through email? Please refer to > Show quote > 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/subscriptions/support/default.aspx. > ================================================== > This posting is provided "AS IS" with no warranties, and confers no rights. >  |
|||||||||||||||||||||||
Other interesting topics