This project has moved. For the latest updates, please go here.

Should we support Silverlight 3

Nov 16, 2009 at 7:45 AM

Hey Guys,

Should we add Silverlight 3 as a supported platform?  I took a quick look at the code (after a request in the dnA forum) and it seems that the only major change would be to the Parallel class. We would need to go back to the wait/notify design instead of using semaphores. I'll do some benchmarking to see if we'll take a performance hit.  There are some minor things will have to do such as wrap the serialization attributes and P/Invoke code in #if !SILVERLIGHT blocks. 

I'm for it, since I have a SL project that I want to use MathNET Numerics in - though it keeps getting pushed back.

What do you guys think? 

Regards,
Marcus

Coordinator
Nov 16, 2009 at 9:34 AM

Hi Marcus,

I think this is an excellent idea. I don't know anything about Silverlight or its limitations but if it is just the Parallel class it seems reasonable to support Silverlight. Keep us posted on the performance ...

Cheers, Jurgen

 

Nov 29, 2009 at 7:00 AM

Hey Guys,

I've added a Silverlight branch to my fork and made the necessary changes so it compiles under Silverlight.  There is no difference in performance when using wait/pulse over semaphores - but the code isn't as clean.  

I've run into one problem. It looks like MbUnit doesn't support and doesn't plan to support Silverlight.  I'm looking into if we can use NUnit.

Thanks,
Marcus

 

Dec 1, 2009 at 11:42 AM

Looks like there will be Silverlight support in NUnit 3 - it is suppose to be added in the next pre-release (2.9.4).  I'll merge the current changes and revisit the unit tests once 2.9.4 is out.

Coordinator
Dec 1, 2009 at 12:30 PM

Very cool! I look forward to try this out ...

Coordinator
Dec 12, 2009 at 10:33 PM

hey Marcus,

I downloaded Silverlight through the web platform installer but can't open the project in the Math.Net Solution. Is there anything special that I need?

Cheers, J

Dec 13, 2009 at 6:44 PM

Hey Jurgen,

I just installed the Silverlight 3 SDK - that should be included in the Web platform installer. Maybe it is a version mismatch. I'm using 3.0.40818. 

What is the error message?

 

Thanks,

Marcus

Coordinator
Dec 14, 2009 at 11:59 PM

Very strange. I have the same version but when I open Math.Net I get a message "The project file ...\Silverlight.csproj cannot be opened. The project type is not supported by this installation."

J

Coordinator
Dec 17, 2009 at 1:33 PM

OK, I think it has something to do with my visual studio installation. I think it is messed up as I don't see Silverlight 3 projects in the "New Project" window. I will try it on a different machine then ...

J

Coordinator
Feb 2, 2010 at 8:26 AM
Edited Feb 2, 2010 at 9:37 AM

It seems the current ThreadQueue implementation is broken by dead-lock on single core machines, which might have been caused by this new wait/notify pattern as discussed above (unless it was already broken before). It is also reproducible on multi-core machines when manually setting the process CPU affinity to only one core.

Failing Tests:

  • ParallelForTests.DoesNotGetConfusedByMultipleStartShutdown
  • ParallelForTests.ParallelForInvokesEveryItemOnceMTAOnePerCore(2) (0,1 succeed)
  • ParallelForTests.ParallelForInvokesEveryItemOnceMTAOnePerCoreWithIntialAndFinally(2) (0,1 succeed)

The first also fails on a single core machine, the last two seem to succeed there, but fail on a multi-core machine with restricted CPU affinity on the process (so the framework thinks it has two or more cores, but it only every gets scheduled on the single selected one of the cores)

Coordinator
Feb 2, 2010 at 9:37 AM

Instead of replacing the Semaphores with wait/notify, couldn't we instead just implement the Semaphore ourselves in case of Silverlight? Implementing a Dijkstra Counting Semaphore is tricky, but doable based on the framework-provided monitor (wait/notify), I actually have an implementation ready (but have not tested yet whether it would resolve the issue).

Feb 2, 2010 at 10:48 AM
Edited Feb 5, 2010 at 5:45 PM

I can take a look at the current implementation on Friday.  Wait/notify wasn't any slower than using semaphores. 

 

On Feb 2, 2010 11:37 AM, "cdrnet" <notifications@codeplex.com> wrote:

From: cdrnet

Instead of replacing the Semaphores with wait/notify, couldn't we instead just implement the Semaphore ourselves in case of Silverlight? Implementing a Dijkstra Counting Semaphore is tricky, but doable based on the framework-provided monitor (wait/notify), I actually have an implementation ready (but have not tested yet whether it would resolve the issue).



Read the full discussion online.

To add a post to this discussion, reply to this email (mathnetnu...

 

Feb 5, 2010 at 9:29 AM

The problem was with shutting down the thread queue. The isRunning check needed to be placed inside the lock statement.  The thread was going right back to sleep and would never "join".

The tests now pass on a dual core machine with restricted CPU affinity.

Chris, could you verify that it works on a single core machine?

Thanks,

Marcus

Coordinator
Feb 5, 2010 at 5:39 PM

Yes, the tests all run fine now. Thanks for looking into it!

Thanks,
Chris