Arlie,
I wrote a .NET logging package that is many times faster than other available implementations, but I didn't check it with Mono. The code has to be multithreaded, but also fast. In buffering mode, each logger has a buffer into which a thread can push an event (read as "log record" if you like), and a separate internal thread periodically pushes the contents to output. In order to increase speed, I made it so that there are actually two rotating buffers: the one being written to by external threads is separate from the one being used by the logger. I need to synchronize on the "external" buffer for external access, the "internal" buffer for internal access, and both of them during the swap. This lets me avoid lots of performance-killing nastiness, and external threads can keep logging (basically without interruption) as the internal thread goes about its business. This trick lets my logging package log thousands of times faster than (for instance) the package "log4net", especially in multithreaded situations. I built the package with performance and usability in mind; I need high performance for something I'm writing. I have used this technique in a few other places, too. It seems to be a logical extension of the idea that when synchronization is necessary, you should reduce synchronized areas to reduce the chance of a lock contention. When you have multiple concerns operating in the same space but they only sometimes overlap (such as in large in-memory structures), partitioned locking can really give a good performance boost. I found the problem, and another reader also found it. I was being stupid-- it's the last curly brace that throws the problem. I didn't know that use of the "lock" keyword compiles to the same code as calls to Monitor methods, but now I do. Your RTFM suggestion (although more nicely worded) was definitely in order! :O) I wasn't trying to bust on Mono-- I knew it was likely to be my screwup. Thanks a lot to everyone who responded or thought about my problem. Yours, Jeff --- Arlie Davis <[EMAIL PROTECTED]> wrote: > #1 - Why are you trying to do this? This doesn't look like it performs > anything useful. > > #2 - It appears that Microsoft's implementation is more accepting than > the specifications for Monitor.Exit. The docs are pretty clear. > > -- arlie > > > -----Original Message----- > From: Moderated discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Varszegi > Sent: Friday, October 17, 2003 10:59 AM > To: [EMAIL PROTECTED] > Subject: [ADVANCED-DOTNET] Synchronization question > > > I've written some code that runs fine on Windows, but when someone tried > to run it under Mono, it threw this exception: > > Unhandled Exception: System.Threading.SynchronizationLockException: Not > locked by this thread > > The code in question is pretty detailed, but the synchronization scheme > boils down to this: I have two overlapping (avoiding the word > "interlocked") synchronized regions, where I start, the first, start the > second, exit the first, then exit the second, like this: > > object monitor1 = new object(); > object monitor2 = new object(); > lock (monitor1) { > // ... > lock (monitor2) { > Monitor.Exit(monitor1); > // ... > } > } > > I was thinking that this might be because the Mono implementation > requires that if you use the Monitor class to release a lock, you must > have used it to acquire the same lock (since it must be just holding a > handle to the current thread set when you called the Enter() method), > and Microsoft's .NET wasn't built that way. This brings up the question > of whether this behavior is part of the platform specification. Any > quick answers for this .NET newbie? > > Thanks in advance, > > Jeff > > =================================== > This list is hosted by DevelopMentorR http://www.develop.com NEW! > ASP.NET courses you may be interested in: > > 2 Days of ASP.NET, 29 Sept 2003, in Redmond > http://www.develop.com/courses/2daspdotnet > > Guerrilla ASP.NET, 13 Oct 2003, in Boston > http://www.develop.com/courses/gaspdotnet > > View archives and manage your subscription(s) at > http://discuss.develop.com > > =================================== > This list is hosted by DevelopMentorŪ http://www.develop.com > NEW! ASP.NET courses you may be interested in: > > 2 Days of ASP.NET, 29 Sept 2003, in Redmond > http://www.develop.com/courses/2daspdotnet > > Guerrilla ASP.NET, 13 Oct 2003, in Boston > http://www.develop.com/courses/gaspdotnet > > View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentorŪ http://www.develop.com NEW! ASP.NET courses you may be interested in: 2 Days of ASP.NET, 29 Sept 2003, in Redmond http://www.develop.com/courses/2daspdotnet Guerrilla ASP.NET, 13 Oct 2003, in Boston http://www.develop.com/courses/gaspdotnet View archives and manage your subscription(s) at http://discuss.develop.com
