Thank you very very much buddy, Yes that really helped and clarified a lot for me :-) I wish I can help u back some day.

--- "Art happens when you least expect it."

Sample: Here I have a collection class that I want to be thread safe for reading from and manipulation (Not also in the case of iterations). It is assumed any number of threads may enter any of the methods or indexers at the same time. I think for reading from indexers there is no need for a lock, even if there is a chance for more than one thread to enter the indexers, and/or at the same time to one of the Add, Remove, Clear methods. Is it correct? (sorry I don't know how to format code snippets in the post) internal class MyThreadSafeCollection : System.Collections.Specialized.NameObjectCollectionBase { const int readLockTimeout = 100; const int writeLockTImeout = 100; private ReaderWriterLock rwLock = new ReaderWriterLock(); public MyThreadSafeCollection() { } public object this[int index] { get { rwLock.AcquireReaderLock(readLockTimeout); // IS THIS REQUIRED ?? try { return BaseGet(index); } finally { rwLock.ReleaseReaderLock(); } } } public SocketClientData this[string id] { get { rwLock.AcquireReaderLock(readLockTimeout); // IS THIS REQUIRED ?? try { return BaseGet(id); } finally { rwLock.ReleaseReaderLock(); } } } public void Add(string id, SocketClientData client) { rwLock.AcquireWriterLock(writeLockTImeout); // I Know it is required. (isn't it?) try { BaseAdd(id, client); } finally { rwLock.ReleaseWriterLock(); } } public void Remove(string id) { rwLock.AcquireWriterLock(writeLockTImeout); // I Know it is required. (isn't it?) try { BaseRemove(id); } finally { rwLock.ReleaseWriterLock(); } } public void Clear() { rwLock.AcquireWriterLock(writeLockTImeout); // I Know it is required. (isn't it?) try { BaseClear(); } finally { rwLock.ReleaseWriterLock(); } }

Thank you very much for the helpful info yo provided. But I still need dedicated replies on the three situations I explained in details.

--- "Art happens when you least expect it."

Hello everybuddy, I am a little confused about why reading and writing a resource concurrently may be unsafe in some scenarios as I explain: 1. Blocking multiple threads from writing a resource based on its current value (such as incrementing some number, or manipulating some collections) is logical and I have no problem with it. 2. Blocking multiple threads from setting a resource to some new value independent of its current value seems unnecessary in my opinion, I need some clarification by some friend here why such synchronization is required. (more details: while there is no guarantee that if we block at start of the write process, which thread enters the section first, then that should not be important in not-locking scenario, which thread completes actual write instructions first and the other overwrites it, so why should we lock?! ). 3. Blocking two threads that one is writing the resource and another is reading it, also seems unnecessary, again I need clarification. (More details: Again we don't know which thread enters the locked section first, so that should not be important in not-locking scenario if the reader thread reads the value before the write process completely takes place or after that). Thank you so much for any help - den2fly

--- "Art happens when you least expect it."

Yes, useful comment. Thank you for your note. --- "Art happens when you least expect it."

Hi everybuddy, I wana ask in your opinion how a 'Middleware' relates to or differs from an 'Application Server' such as ASP.NET? Can we say one of these concepts contains the other? or they are different tools that help achieveing a similar goal? Thank you, - Den2Fly --- "Art happens when you least expect it."

Yes, I see. So it is one other usage of delegates. Thank you --- "Art happens when you least expect it."

Let me add some notes: 1. A Delegate is a type that is used to construct delegate objects that refrence functions with the same signature as delegate. Just like classes that construct objects. 2. When a delegate object is created with some function name in its constructor, that object will be indirect agent of that function, and this happens RUNTIME. It is important because when you create a compiled class for your users you don't know what functions they will create to bind as their callbacks or event handlers so you call them directly, so there should be some indirect way for them to introduce their functions and that is Delegate! I hope that is useful - Mohammad --- "Art happens when you least expect it." -- modified at 1:06 Tuesday 13th December, 2005

Gerben I think your second reason is wrong while the calling method whether directly or using its delegate run in the same thread as caller function, it doesn't continue to next statement until the called method(s) return. --- "Art happens when you least expect it."

Thank you so much leppie, you have helped me lots of times, I hope I can help u back someday buddy :-) --- "Art happens when you least expect it."

Hi buddies, I have created a remote object in another AppDomain, after a short time of inactivity it seems to be disconnected and removed because next time I call some method on it, an exception says that the object doesn't exists or it is disconnected. How can I set lifetime of remote objects? May I set it to live till I explicitly remove it ? Thank you so much, - Mohammad --- "Art happens when you least expect it."

Thank yo leppie --- "Art happens when you least expect it."

Thank you leppie --- "Art happens when you least expect it."

Yes, thank you Guffa. --- "Art happens when you least expect it."

Hi buddies, If more than one thread may enter .NET collections (ArrayList, NameObjectCollectionBase, ...) Add() methods should I enclose the code that calls Add() in a lock statement? Also can you tell me a general rule to underestand when I SHOULD call some method only inside a lock statement in a multi-threaded app? Thank you so much, - Mohammad --- "Art happens when you least expect it."

Yes, that solved it, Thank you Andy very much :-) --- "Art happens when you least expect it."

Hi buddies, Suppose we have created an AppDomain with FriendlyName "NewDomain" in the current AppDomain named "CurrentDomain" and have created an instance of class A in that, now we call some method of that instance, Here is the code: AppDomainSetup domainSetup = new AppDomainSetup(); domainSetup.ApplicationBase = @"c:\myApp"; domainSetup.ShadowCopyDirectories = @"c:\myApp"; domainSetup.LoaderOptimization = LoaderOptimization.SingleDomain; AppDomain appDomain = AppDomain.CreateDomain("NewDomain", null, domainSetup); // Here the constructor is called in the 'NewDomain' domain A obj = (A)appDomain.CreateInstanceAndUnwrap(assemblyName, "A"); // Here the 'MyMethod' is called in the current application domain obj.MyMethod(); While tracing "AppDomain.CurrentDomain.FriendlyName" in class A, I see: 1. In its constructor scope, it is "NewDomain", that is ok 2. In the called method scope, it is "CurrentDomain". It means that the method is called in the 'CurrentDomain', while I wana the method be called in the "NewDomain" application domain. How can I perform it ? Thanks --- "Art happens when you least expect it."

Thanks for your note; So it seems there is no way to do it without windows services? yes? By the way it is not possible to create a windows service in a web application on the fly, isn't it ? --- "Art happens when you least expect it."

Its an interesting idea, but note that in my situation it is not a value type or a composite of value types, its an object that is doing something in its lifetime, and I want to keep it alive. --- "Art happens when you least expect it."

Hi friends, Its a while I am looking for a way to keep some object in ASP.NET server memory permanently without loosing it at Application_End event, Is there any way? - Mohammad --- "Art happens when you least expect it."