Multi threading in windows phone C# ?
How to do multithreading when i call a wcf service . One thread should call service and one thread should show processing.
I've never programmed for windows phone but I have a fair bit of experience with c# and a quick google search shows windows phone has support for BackgroundWorkers. I would suggest using that for your time consuming task, you can even get a progress update. Check this out for an example:
http://msdn.microsoft.com/en-us/library/windowsphone/develop/cc221403(v=vs.105).aspx
It's what I use when calling a WCF service from a WPF app
WP7 has a BackgroundWorker class that can help you.
It has the WorkerReportsProgress property and ProgressChanged event that can inform you about its progress.
BackgroundWorker seems like a good choice given your description of the problem. It is pretty easy to work with. But it is also worth mentioning that there are other methods to do multithreading on Windows Phone 7 such as a ThreadPool.
I can recommend checking out this question (and answers) which describe the possible options:
Background Threads in Windows Phone
Related
In Apple's docs I have found an article how to execute a finite-length task when exiting the application. I am looking for a way to adopt that in MonoTouch.
The idea is to process some data if the user pushes the app into background, but that processing takes longer than the time I'm granted by default, hence I want to use the functionality describe here: http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/BackgroundExecution/BackgroundExecution.html to get more time.
How does the code translate into MT? Has anybody an example?
I have a blog post with an example for MonoTouch: http://software.tavlikos.com/2010/12/08/multitasking-in-ios-the-monotouch-way-part-i/
What thread synchronization mechanisms are available in VB6?
None natively, If you do threading in VB6, you'll iether have to make heavy use of the threading Windows API functions (for good info on this see Dan Applemans books or the Matthew Curland book "Power Techniques for Everyday Programmers")
You can also do threading via COM via timers and COM apartment threading, but that also requires quite a bit of framework code, and even then, you still have to code the synch functionality yourself.
There are no built-in thread synchronization mechanisms - use Win32 API calls to access built-in windows synchronization mechanisms. See this example
Just to confirm if multithreading is supported in iPad and iPhone. I need to write an application that calls a web service on a background thread while user can still interact with the UI.
Yes, it has threads.
Also, you don't need to spawn your own threads for most tasks. A lot of the Apple Frameworks (Cocoa Touch Foundation frameworks) have built-in code that will do this for you.
Also, if you're consuming data from a Web API (HTTP Request), I highly recommend you take a look at ASIHTTPRequest, which is built on top of NSOperation (an operation class that easily handles background processing).
Finally, if you need help on program design/flow using the Model-View-Controller pattern, I've written a blog entry describing how to consume Web API data and present it to the end-user in a table format.
iOS has always supported multi-threading, just as Mac OS X did before it. Here's Apple's excellent overview documentation on the subject:
Concurrency Programming Guide
While multithreading is faster in some cases, sometimes we just want to spawn multiple worker processes to do work. This has the benefits of not crashing the main app if one of the worker crashes, and that the user doesn't need to worry a lot about inter-locking stuffs.
COM+'s Application Pooling seems like a good way to achieve this on Windows. The downside is that we need to write a COM+ wrapper for the worker process.
However, when I search for Application Pooling on Google, it seems like most of its usages are related to IIS. Don't other applications (such as scientific/graphics) find it useful to spawn multiple worker processes?
So there are several questions:
Why isn't COM+ more popular in areas other than IIS? If I write a non-IIS application and want to use process management on Windows, should I go with COM+ or are there better alternatives out there?
What would be the cross platform way to do it? Are there libraries out there that give me a "process pool" (worker processes will intelligently pick up work, can be managed, etc.)
I can't offer any answers to the COM aspect of your question, but it's worth noting there's another world (besides HPC MPI) where multi-processing (rather than the more common multi-threading approach) is apparently alive, well and thriving: Python.
Why ? Python's GIL ("global interpreter lock") cripples most attempts to multithread python code so badly that multiprocessing is the generally recommended approach to parallelising Python on SMP. The standard library includes process pools; there are various other options too.
Python certainly ought to satisfy any multi-platform requirement!
You might want to investigate how the apache web server manages process pools. From version 2.0 it runs natively on windows and one of the multi-processing models it supports are process pools. A part of apache is also APR (apache portable runtime), which handles platform-specific issues.
No one can answer why something is not popular because may be no body is looking for what you are looking for. After .NET came in picture, people shifted from COM to Managed Environment, before .NET, COM and ATL and relative other technologies were quite painful to implement and they would crash and were also quite difficult to debug.
That is the reason, managed environment came in existence.
However, .NET 4 onwards, parallel libraries give much more power to user for parallel programming and also you can spawn and control other proceeses.
For multiplatform, you can look for zvrba's answer.
Yes, other applications--especially science applications--find it useful to spawn multiple processes. Since few super-computers run Microsoft Windows, scientists generally avoid using anything that ties them to a Microsoft platform. Nothing related to COM will help scientists leverage their enormous existing code base written in Fortran.
People who choose to run IIS have generally already drunk the Microsoft Koolaid, so they have fewer inhibitions to tying themselves to Microsoft's proprietary platforms, which is why COM-specific terminology will get lots of hits related to IIS.
One of the open standards for doing what you want is the Message Passing Interface. Several implementations exist and some of them run on supercomputers using Fortran. Some of them run on cheaper computers using sexier languages.
See http://en.wikipedia.org/wiki/Message_Passing_Interface
There hasn't been a mob rushing through the doors of COM application pooling primarily because of two factors:
COM is a pain in the ass to deal with compared to just about anything else
Threading can be a headache, but it's a lot easier and more convenient to manage than inter-process communication
COM application pooling was essentially created for IIS. It has one very specific benefit over normal multithreading: the multiple processes are fully isolated from each other. This is important for data security and for app stability when dealing with third party plugins of questionable stability.
Scientific computing generally doesn't need strong data security isolation between operations, and I would venture to guess that scientific computing doesn't rely much on third party plugins of questionable stability. When doing big math operations, you're either using a sexy numerics library that had better be rock solid to be taken seriously, or you're using your own code, in which case crashes should be fixed and repeat offenders should be spanked.
Oh, and all crashes except stack overflow can be trapped and dealt with within a multithreaded app, especially if it's your own code.
In short, COM app pooling is overkill for just about anything other than IIS.
Google's webbrowser chrome is a multi-process architecture software. It is open source, so you can check out its code and see how to manage processes.
A number of years ago I implemented an asynchronous peer-to-peer Message-Oriented-Middle-ware that was very friendly to use in Excel VBA, and I find myself again needing to do lots of calculations which could be trivially distributed, if I had the mechanism.
I could re-implement the MOM layer, but I'd prefer to use a third party product if one existed.
My requirements are these:
to be able to send messages easily from Excel VBA and VB6,
to have a resource discovery mechanism to find the calculation services,
to have asynchronous message sends (I don't want to lock up Excel while the calculation is being done),
to provide a queuing mechanism so I can have multiple servers doing the work easily,
to have low admin for setup
Can anyone suggest anything?
Many thx
-- DM
The next release of Microsoft Windows Server 2008 HPC edition includes something called "Excel Runner" which is specifically designed to deal with the kind of problem you are describing.
RESTFul Web Services are easy to use from Excel VBA. You can use a reference to MSXML2 or WinHttp - Sounds like you want to use in Async mode so as not to block the Excel UI.
Start with something simple:
Simple discovery (scan your subnetfor worker nodes).
Divide your task up.
Share out tasks.
Wait or poll for results.
Update cells with new results.
If any sub task takes too long round robin again.
Nice to have visual indication on cells pending results.
These links may help you.
Peer-to-Peer Programming with WCF and .NET Framework 3.5
Peer-to-Peer Programming
MPAPI - Parallel and Distributed Applications Framework