What's the right way to do this? (threading/AppDomains)

[Mountain Bikn' Guy]

I need some advice on this. I am working on a fairly complex calculator app
(C#) with lots of functions (and these functions in turn use math functions
from an unmanaged C DLL). A calculation takes a lot of time (up to hours),
and should run on a separate thread from the one that the GUI uses. The GUI
also needs to display various properties for each function (such as
parameters that can be set). It does this with property grid and other grids
(there are lots of functions and some have thousands of properties). The GUI
also needs to display a progress bar, etc. while the calculation is running.

Does it make sense to use two AppDomains? (I'm considering only MBR --
otherwise I don't believe I gain any fault protection.) Will this have any
significant effect on performance? Will the calculator app (server) running
in a 2nd AppDomain perform the same? Will the various property grids
(complex -- with thousands of properties) respond about the same in the GUI?
I'm afraid that updating the GUI as it accesses the calculator functions by
ref across the app domain and then refreshes various large grids will slow
down a lot.

However, I'm in favor of separateAppDoma ins because the calculator needs to
run on a separate thread and because it relies heavily on unmanaged code. At
the moment, something in this unmanaged code seems to be stepping on memory
the GUI is using. I'm looking for the best way to solve this problem and
isolating the unmanaged code in an AppDomain seems like a good foundation to
start with (as long as the performance will remain acceptable).

[Nick Wienholt]

> Does it make sense to use two AppDomains?

I can't see any benefit for using an AppDomain in this situation.
Multi-threading will handle the UI responsiveness issue with no problems,
and as AppDomains sit in the same process, the C DLL stomping over random
memory is not addressed. AppDomains are only effective at isolating managed
components from each other.

If you can't fix the C DLL memory corruption issue, there isn't much option
but to move the DLL to a separate host process (maybe using
EnterpriseServi ces), and move the data back to the GUI app using named pipes
or MMFs or remoting.

Nick Wienholt, MVP
Maximizing .NET Performance
http://www.apress.com/book/bookDisplay.html?bID=217
Sydney Deep .NET User Group www.sdnug.org

"Mountain Bikn' Guy" <[e-mail] > wrote in message
news:qdUpb.7657 6$mZ5.488839@at tbi_s54...

I need some advice on this. I am working on a fairly complex calculator app (C#) with lots of functions (and these functions in turn use math functions from an unmanaged C DLL). A calculation takes a lot of time (up to hours),
and should run on a separate thread from the one that the GUI uses. The GUI also needs to display various properties for each function (such as
parameters that can be set). It does this with property grid and other grids (there are lots of functions and some have thousands of properties). The GUI also needs to display a progress bar, etc. while the calculation is running.
Does it make sense to use two AppDomains? (I'm considering only MBR --
otherwise I don't believe I gain any fault protection.) Will this have any
significant effect on performance? Will the calculator app (server) running in a 2nd AppDomain perform the same? Will the various property grids
(complex -- with thousands of properties) respond about the same in the GUI? I'm afraid that updating the GUI as it accesses the calculator functions by ref across the app domain and then refreshes various large grids will slow
down a lot.

However, I'm in favor of separateAppDoma ins because the calculator needs to run on a separate thread and because it relies heavily on unmanaged code. At the moment, something in this unmanaged code seems to be stepping on memory the GUI is using. I'm looking for the best way to solve this problem and
isolating the unmanaged code in an AppDomain seems like a good foundation to start with (as long as the performance will remain acceptable).

[Mountain Bikn' Guy]

Thank you for your feedback! I was under the mistaken impression that
AppDomains would be effective at isolating the C DLL.

"Nick Wienholt" <go*********@ho tmail.com> wrote in message
news:eo******** ********@TK2MSF TNGP09.phx.gbl. ..

Does it make sense to use two AppDomains?
I can't see any benefit for using an AppDomain in this situation.
Multi-threading will handle the UI responsiveness issue with no problems,
and as AppDomains sit in the same process, the C DLL stomping over random
memory is not addressed. AppDomains are only effective at isolating

managed components from each other.

If you can't fix the C DLL memory corruption issue, there isn't much option but to move the DLL to a separate host process (maybe using
EnterpriseServi ces), and move the data back to the GUI app using named pipes or MMFs or remoting.

Nick Wienholt, MVP
Maximizing .NET Performance
http://www.apress.com/book/bookDisplay.html?bID=217
Sydney Deep .NET User Group www.sdnug.org

"Mountain Bikn' Guy" <[e-mail] > wrote in message
news:qdUpb.7657 6$mZ5.488839@at tbi_s54...

I need some advice on this. I am working on a fairly complex calculator app

(C#) with lots of functions (and these functions in turn use math

functions

from an unmanaged C DLL). A calculation takes a lot of time (up to hours), and should run on a separate thread from the one that the GUI uses. The

GUI

also needs to display various properties for each function (such as
parameters that can be set). It does this with property grid and other

grids

(there are lots of functions and some have thousands of properties). The

GUI

also needs to display a progress bar, etc. while the calculation is

running.

Does it make sense to use two AppDomains? (I'm considering only MBR --
otherwise I don't believe I gain any fault protection.) Will this have any significant effect on performance? Will the calculator app (server)

running

in a 2nd AppDomain perform the same? Will the various property grids
(complex -- with thousands of properties) respond about the same in the

GUI?

I'm afraid that updating the GUI as it accesses the calculator functions

by

ref across the app domain and then refreshes various large grids will slow down a lot.

However, I'm in favor of separateAppDoma ins because the calculator needs

to

run on a separate thread and because it relies heavily on unmanaged

code. At

the moment, something in this unmanaged code seems to be stepping on memory

the GUI is using. I'm looking for the best way to solve this problem and
isolating the unmanaged code in an AppDomain seems like a good

foundation to

start with (as long as the performance will remain acceptable).

[Eric Gunnerson [MS]]

While you could do it through app domains, it will add a considerable amount
of complexity to your code. If you were looking for protection from
"misbehavin g add-in functions", then I think it would make more sense. I
don't think you would have any performance problems using app domains.

I think the problems you're having now will also show up if you use an app
domain, so my recommendation would be to try to fix that problem instead. If
you post the C headers and the C# code that you're using to call those
functions in the framework, interop group, they should be able to help you
fix your problem. If not, you can ping me at er****@microsof t.com.

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
"Mountain Bikn' Guy" <[e-mail] > wrote in message
news:qdUpb.7657 6$mZ5.488839@at tbi_s54...

I need some advice on this. I am working on a fairly complex calculator app (C#) with lots of functions (and these functions in turn use math functions from an unmanaged C DLL). A calculation takes a lot of time (up to hours),
and should run on a separate thread from the one that the GUI uses. The GUI also needs to display various properties for each function (such as
parameters that can be set). It does this with property grid and other grids (there are lots of functions and some have thousands of properties). The GUI also needs to display a progress bar, etc. while the calculation is running.
Does it make sense to use two AppDomains? (I'm considering only MBR --
otherwise I don't believe I gain any fault protection.) Will this have any
significant effect on performance? Will the calculator app (server) running in a 2nd AppDomain perform the same? Will the various property grids
(complex -- with thousands of properties) respond about the same in the GUI? I'm afraid that updating the GUI as it accesses the calculator functions by ref across the app domain and then refreshes various large grids will slow
down a lot.

However, I'm in favor of separateAppDoma ins because the calculator needs to run on a separate thread and because it relies heavily on unmanaged code. At the moment, something in this unmanaged code seems to be stepping on memory the GUI is using. I'm looking for the best way to solve this problem and
isolating the unmanaged code in an AppDomain seems like a good foundation to start with (as long as the performance will remain acceptable).

[Mountain Bikn' Guy]

I am trying, whenever possible, to post the final conclusions reached in
regard to my initial posts. In this post, my fundamental problem was related
to unmanaged code corrupting memory.

The story probably won't surprise some veterans. I had code (including
unmanaged code) that had been working for over a year. And it had been in
hard use under stressful situations. It never exhibited any problems. I
recently began calling it via an async delegate. We also made a lot of GUI
changes and the exceptions were always happening upon one of several
InitializeCompo nent method calls completing.

Naturally, the last place I searched for the problem was in the oldest, most
well-tested, unchanged code. However, that is in fact where the problem was.
We had a RCW on an OCX. One of the OCX methods returned an array thru a
short int pointer. The default interop wrapper marshalled this not as an
array, but as a single element. We only used the first element, so it didn't
matter. However, that incorrect parameter marshalling was the root cause of
all the problems -- but it only showed up when we started calling a method
many levels higher via the async delegate.

Anyway, the problem was solved without the use of a 2nd AppDomain.

My experience underscores the advice Willy gave me on another thread
('System.Execut ionEngineExcept ion' occurred in Unknown Module):

"'System.Execut ionEngineExcept ion' are mostly related to marshaling between
managed and unmanaged code, so maybe you should start to
inspect your PInvoke declarations."

"Mountain Bikn' Guy" <[e-mail] > wrote in message
news:qdUpb.7657 6$mZ5.488839@at tbi_s54...

I need some advice on this. I am working on a fairly complex calculator app (C#) with lots of functions (and these functions in turn use math functions from an unmanaged C DLL). A calculation takes a lot of time (up to hours),
and should run on a separate thread from the one that the GUI uses. The GUI also needs to display various properties for each function (such as
parameters that can be set). It does this with property grid and other grids (there are lots of functions and some have thousands of properties). The GUI also needs to display a progress bar, etc. while the calculation is running.
Does it make sense to use two AppDomains? (I'm considering only MBR --
otherwise I don't believe I gain any fault protection.) Will this have any
significant effect on performance? Will the calculator app (server) running in a 2nd AppDomain perform the same? Will the various property grids
(complex -- with thousands of properties) respond about the same in the GUI? I'm afraid that updating the GUI as it accesses the calculator functions by ref across the app domain and then refreshes various large grids will slow
down a lot.

However, I'm in favor of separateAppDoma ins because the calculator needs to run on a separate thread and because it relies heavily on unmanaged code. At the moment, something in this unmanaged code seems to be stepping on memory the GUI is using. I'm looking for the best way to solve this problem and
isolating the unmanaged code in an AppDomain seems like a good foundation to start with (as long as the performance will remain acceptable).