MethodSynchronizer

• Download source - 23 Kb

Introduction

So, here I got again into another problem, and no search results gave me the answer I was looking for. The software in development was mostly using only one thread to run, but sometimes it could happen that concurrent threads start to run to update some parts of the software (this is a real-time software). That's where I discovered that some methods weren't thread safe. So what could be my solution? I decided to build an object which could be used to synchronize threads within one or more methods of another object (and possibly multiple objects). This object should respond to these criteria:

• Is able to support enough concurrent threads (more than 50)
• Is deployable at least within a singleton object so that all calls made to specific methods are synchronized
• The entry order doesn't have to respect the exit order necessarily
• Is able to make threads wait as long as needed.

Thus was born the MethodSynchronizer!!

Usability

This sample is to test the capacity of the MethodSynchronizer.

The MethodSynchronizer is used to synchronize certain moments in your code where multiple threads could run at the same the time. You have to use one object per synchronization grouping. I mean there that, if for example you have an object which is used to read and write to the DB, then you can use one MethodSynchronizer and call, at the beginning of each DBObject methods, InternalThreadSync method to synch all DB calls. Each end of DBOject method has to have a ThreadIsEnded call to let the flow continue. Otherwise, your program will crash. So, ensure that you have a ThreadIsEnded call each time you use InternalThreadSync for all your code flow possibilities.

This object is really easy to use. The only thing you have to care of is where you declare your MethodSynchronizer object. Because this object isn't a Singleton (search this site for Singleton pattern if needed), you have to ensure that the methods using the MethodSynchronizer use the same MethodSynchronizer. So, if you use this within a singleton object, there is no problem; otherwise, you could declare it at a higher level of your program and make a reference to the object using it.

More

I'm been using this sample to get up to 948 concurrent threads processed one after the other. After that, an OutOfMemoryException is thrown by the program.

The reason why I didn't create this object as a Singleton is because I wanted to have the possibility to lock different parts of my software at the same time but not together. So one is independent of the other.

This object should be used when you have to lock for something that could take time. This is really useful when you get external access to your software, which could be anything like DB access, file, webpage, network,... and you only want ONE thread at a time to execute this code.

I hope this could be more useful! If you have questions or comments, send them to thecodeproject@cints.net, or use the forum below.

You must Sign In to use this message board.

FAQ    Noise Tolerance Very HighHighMediumLowVery Low   Layout Expand Posts & RepliesThread ViewNo JavascriptNo JS + Preview   Per page 102550

Msgs 1 to 11 of 11 (Total in Forum: 11) (Refresh) FirstPrevNext

Why roll your own ArchAngel123 6:23 10 Oct '06   Why not just use one of the various synchronization classes already available - what's this doing above and beyond those? Sign In·View Thread·PermaLink Re: Why roll your own Master DJon 7:45 10 Oct '06   The synchronisation methods existing in .NET (lock in C# or SyncLock in VB.NET) exist mostly for atomic operations. This object is designed to support long tasks synchronization. So there is no time out. This could cause some problems, for sure, but if you need a time out, it is really easy to add one. More... when you use the preset sync methods you cannot start the locking in one method and end it in another. Which you can with this object. Hope I answered you correctly. Sign In·View Thread·PermaLink Re: Why roll your own ArchAngel123 9:42 10 Oct '06   I wasn't talking about semantic controls like lock and Synclock. I was referring to already existing framework objects like Mutex, Monitor, ReaderWriterLock, etc. which can be used to synchronize multiple threads across non-atomic operations and could be used across methods invocations and across multiple objects. Sign In·View Thread·PermaLink Re: Why roll your own Master DJon 15:43 10 Oct '06   You are probably right on this one. But you know, by my experience, I always get problems when it comes to touchy things and I use microsoft things. Anyhow, even though it could maybe solve my problem, I coudn't personalize it as I am able to do with this object. I'm one of these programmers which like his own thing. I'm sure you're aware of this behavior on programmers. Thanks for your reply & comments Sign In·View Thread·PermaLink 1.00/5 (1 vote) Re: Why roll your own Filip Duyck 0:51 13 Oct '06   You are experience "Not Invented Here"-syndrome. You went through the time and effort of writing your own mechanism, without looking at existing procedures. If you had done that, you'd had noticed there's nothing your class can do that the standard mechanisms can't. You've chosen your own class over something that has been tested and used by a large number of people before you. Get rid of that, really. It's not a good thing. Sign In·View Thread·PermaLink Re: Why roll your own - Added some Master DJon 15:46 10 Oct '06   And.. by the way, if this object can be improve, I'm still open !! Sign In·View Thread·PermaLink 1.00/5 (1 vote) I didn't get the problem MaxGuernsey 18:57 9 Oct '06   What problem was this meant to solve? Sign In·View Thread·PermaLink 5.00/5 (1 vote) Re: I didn't get the problem Master DJon 7:47 10 Oct '06   See the thread above... Why roll your own. Sign In·View Thread·PermaLink Re: I didn't get the problem MaxGuernsey 18:43 10 Oct '06   So is your stand that the existing mechanisms provided in System.Threading are insufficient? ...or is it that they are not stable enough for you to depend directly on them? In either case, I would be very interested in hearing about a problem that MethodSynchronizer solves that System.Threading could not address. Sign In·View Thread·PermaLink Re: I didn't get the problem Master DJon 2:43 11 Oct '06   Well, in fact I am not quite sure if there is something more this object can do, but for sure what you got here is similiar to Monitor object. Here, before to continue, I'd like to ask you if you tried my object and if you looked at it ? To continue... It's true, I didn't test the performance (in term of number of maximum of waiting threads) for the Monitor object. I don't have much time these days, but if you could test this out for me, would be nice. --> Take this sample and replace my MethodSynchronizer object by the Monitor object. After than, tell me how many threads you were able to put in wait, and tell me the comparaison of usage between both (using word as easier, faster, tougher, etc). Sign In·View Thread·PermaLink 1.00/5 (1 vote) Re: I didn't get the problem MaxGuernsey 7:57 11 Oct '06   I'm glad to hear you're so busy and I did look through your class. Unfortunately I am also very busy these days. I recommend that, when you have time, you check out the System.Threading namespace. -- Max Sign In·View Thread·PermaLink

Last Visit: 8:47 9 Nov '09     Last Update: 8:47 9 Nov '09 1