Massive(!) ReaderWriterLock bottleneck

[LKeene]

Hello fellow Mono+Mac coders.

I've had a couple of posts in the MacOS section of the Mono forum inquiring about any known bottlenecks in Mono on OSX. This was due to some strange behavior my WinForms app was delivering when running on Mac, whereas on Windows and Linux all was well. I've finally tracked down the source and it seems to be Mono's implementation of the ReaderWriterLock class. I'm using an asynchronous strategy to read/process binary files...essentially I have one thread reading chunks from the disk and then passing it off to a cluster of worker threads that process the data. While the worker threads process the data, the read thread goes ahead and reads the next chunk, etc. I use the ReaderWriterLock to synchronize the operation.

This method is working very well on Windows and Linux i.e. I am able to completely hide the processing time "inside" the latency of the read operation on my Core i7. To process my entire binary test file takes approx. 0.4 seconds on Win/Linux. The problem arises when running the same app on Mac. The time goes from 0.4 sec to 12+ seconds. After looking everywhere else for the bottleneck, out of desperation I dropped the number of worker threads to 1 (now using 1 read thread and 1 worker thread, same synchronization). The execution time on Win/Linux remains very similar (around 0.4 secs) but the execution time on Mac drops from 12 secs to 0.5 secs. Increasing the number of worker threads to 7 bumps up the execution time to 12+ seconds again.

I don't know what is causing this, but for now I would recommend anyone trying to use the ReaderWriterLock class to consider "rolling their own" via synchronization primitives.

Anyone else see this behavior?

-L

[Rodrigo Kumpera]

Mono's RWLock uses CLR monitors, so it's not trivial to improve over it.

On Thu, Sep 24, 2009 at 1:19 PM, LKeene <lionel.keene@...> wrote:

Hello fellow Mono+Mac coders.

I've had a couple of posts in the MacOS section of the Mono forum inquiring
about any known bottlenecks in Mono on OSX. This was due to some strange
behavior my WinForms app was delivering when running on Mac, whereas on
Windows and Linux all was well. I've finally tracked down the source and it
seems to be Mono's implementation of the ReaderWriterLock class. I'm using
an asynchronous strategy to read/process binary files...essentially I have
one thread reading chunks from the disk and then passing it off to a cluster
of worker threads that process the data. While the worker threads process
the data, the read thread goes ahead and reads the next chunk, etc. I use
the ReaderWriterLock to synchronize the operation.

This method is working very well on Windows and Linux i.e. I am able to
completely hide the processing time "inside" the latency of the read
operation on my Core i7. To process my entire binary test file takes approx.
0.4 seconds on Win/Linux. The problem arises when running the same app on
Mac. The time goes from 0.4 sec to 12+ seconds. After looking everywhere
else for the bottleneck, out of desperation I dropped the number of worker
threads to 1 (now using 1 read thread and 1 worker thread, same
synchronization). The execution time on Win/Linux remains very similar
(around 0.4 secs) but the execution time on Mac drops from 12 secs to 0.5
secs. Increasing the number of worker threads to 7 bumps up the execution
time to 12+ seconds again.

I don't know what is causing this, but for now I would recommend anyone
trying to use the ReaderWriterLock class to consider "rolling their own" via
synchronization primitives.

Anyone else see this behavior?

-L
--
View this message in context: http://www.nabble.com/Massive%28%21%29-ReaderWriterLock-bottleneck-tp25577788p25577788.html
Sent from the Mono - OSX mailing list archive at Nabble.com.

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

[Michael Hutchinson]

On Thu, Sep 24, 2009 at 12:19 PM, LKeene <lionel.keene@...> wrote:
> I don't know what is causing this, but for now I would recommend anyone
> trying to use the ReaderWriterLock class to consider "rolling their own" via
> synchronization primitives.

Have you tried ReaderWriterLockSlim? It's supposed to be safer and
more performant.

--
Michael Hutchinson
http://mjhutchinson.com
_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

[Michael Hutchinson]

On Sat, Oct 17, 2009 at 8:55 AM, Rodrigo Kumpera <kumpera@...> wrote:
> Mono's RWLock uses CLR monitors, so it's not trivial to improve over it.

So does that mean the Monitor implementation on Mac is slower?  If so,
is it due to the OS or Mono?

--
Michael Hutchinson
http://mjhutchinson.com
_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx

[Rodrigo Kumpera]

On Sat, Oct 17, 2009 at 11:40 PM, Michael Hutchinson <m.j.hutchinson@...> wrote:

On Sat, Oct 17, 2009 at 8:55 AM, Rodrigo Kumpera <kumpera@...> wrote:
> Mono's RWLock uses CLR monitors, so it's not trivial to improve over it.

So does that mean the Monitor implementation on Mac is slower?  If so,
is it due to the OS or Mono?

Yes, mono on OSX is slower than on linux, but this should not come out of surprise to anyone,
as linux is our main target. Most of the differences are slight small performance gaps for things
that haven't been implemented. None of those differences affect mono's scalability on OSX.

On the other hand, OSX is known for it's kernel slow primitives, so contended monitors should
be slower, no idea on the scalability of it, thought.


Rodrigo

_______________________________________________
Mono-osx mailing list
Mono-osx@...
http://lists.ximian.com/mailman/listinfo/mono-osx