Thread management in .NET (Business logic and UI)

This would be overkill for serial operations. If the operations are
short-lived, then just use the ThreadPool class and call the
QueueUserWorkIt em method, passing a delegate which points to the code you
want to execute on a thread from the thread pool. Then, you can have that
code call the Invoke method when you need to perform UI updates (assuming
that you need to update the UI from that logic).

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"salberts" <al************ ***@gmail.comwr ote in message
news:11******** **************@ y66g2000hsf.goo glegroups.com.. .

>
Hi,

I am writing an application that has its UI and Logic layers. My
initial idea was to launch the two layers on two different threads and
manage calls made by the UI to the Logic manually. Which means
handling the Sleep/Wakeup of the logic thread all by myself. This
looks reasonable to me in the way that the UI and the Logic run
separately and only send messages to each other. The main disadvantage
of thos method is that I have to manage my threads/locks by myself.

A friend of mine advised me to avoid the thread handling and use the
Invoke mechanism instead. I don't really like the idea because it
breaks the logical flow and the structure of the program. In addition
I still have to implement the various locks.

The Logic layer basically has serial flow and does not require multi
threading except when interacting with the UI.

I would be happy to hear you comments.

In .NET 2.0 and later, take a look at the Background worker class. It's
designed for this type of processing.

Mike Ober.

"salberts" <al************ ***@gmail.comwr ote in message
news:11******** **************@ y66g2000hsf.goo glegroups.com.. .

>
Hi,

I am writing an application that has its UI and Logic layers. My
initial idea was to launch the two layers on two different threads and
manage calls made by the UI to the Logic manually. Which means
handling the Sleep/Wakeup of the logic thread all by myself. This
looks reasonable to me in the way that the UI and the Logic run
separately and only send messages to each other. The main disadvantage
of thos method is that I have to manage my threads/locks by myself.

A friend of mine advised me to avoid the thread handling and use the
Invoke mechanism instead. I don't really like the idea because it
breaks the logical flow and the structure of the program. In addition
I still have to implement the various locks.

The Logic layer basically has serial flow and does not require multi
threading except when interacting with the UI.

I would be happy to hear you comments.

salberts <al************ ***@gmail.comwr ote:

I am writing an application that has its UI and Logic layers. My
initial idea was to launch the two layers on two different threads and
manage calls made by the UI to the Logic manually.

Why? I don't see any benefit in introducing threading here.

A friend of mine advised me to avoid the thread handling and use the
Invoke mechanism instead.

Well, you certainly need to use extra threads for long-running
operations (assuming it's a WinForms app) but that doesn't actually
"avoid" thread handling.

The Logic layer basically has serial flow and does not require multi
threading except when interacting with the UI.

In that case don't introduce threading artificially. Life is hard
enough without adding complexity for no benefit :)

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

"salberts" <al************ ***@gmail.comwr ote in message
news:11******** **************@ y66g2000hsf.goo glegroups.com.. .

>
Hi,

I am writing an application that has its UI and Logic layers. My
initial idea was to launch the two layers on two different threads and
manage calls made by the UI to the Logic manually. Which means
handling the Sleep/Wakeup of the logic thread all by myself. This
looks reasonable to me in the way that the UI and the Logic run
separately and only send messages to each other. The main disadvantage
of thos method is that I have to manage my threads/locks by myself.

A friend of mine advised me to avoid the thread handling and use the
Invoke mechanism instead. I don't really like the idea because it
breaks the logical flow and the structure of the program. In addition
I still have to implement the various locks.

The Logic layer basically has serial flow and does not require multi
threading except when interacting with the UI.

I would be happy to hear you comments.

The real art of multi-threading is how to avoid them as much as possible, if you can't, for
instance if you don't want to freeze the UI while executing a long running task, or (and) if
you *can* take advantage of some form of parallelism offered by running multiple threads ,
then the art is to use them sparingly/wisely.
From your description I don't see the need to introduce threads, unless the "Logic Layer"
falls into the category of long running tasks.

Willy.

On Mar 20, 10:07 pm, Jon Skeet [C# MVP] <s...@pobox.com wrote:

salberts<albert .achtenb...@gma il.comwrote:

I am writing an application that has its UI and Logic layers. My
initial idea was to launch the two layers on two different threads and
manage calls made by the UI to the Logic manually.

Why? I don't see any benefit in introducing threading here.

A friend of mine advised me to avoid the thread handling and use the
Invoke mechanism instead.

Well, you certainly need to use extra threads for long-running
operations (assuming it's a WinForms app) but that doesn't actually
"avoid" thread handling.

The Logic layer basically has serial flow and does not require multi
threading except when interacting with the UI.

In that case don't introduce threading artificially. Life is hard
enough without adding complexity for no benefit :)

--
Jon Skeet - <s...@pobox.com >http://www.pobox.com/~skeet Blog:http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

Hi,

First of all thanks for all the quick replies. I think I understand
the direction all who replied is heading to. I just want to clarify
what my program does.

The "Logic" is a process (not the operation system term) that does
some computational work. Its interaction with the UI is done to
accomplish three main tasks:

1. Send output to the user.
2. Ask for input from the user. And later on recieve the input
response.
3. Receive command from user (such as back, finish, terminate, etc)

So it is a continuous work flow and not a bunch of separated
computational actions such as DoTransaction() . In addition since the
input request/response is done asynchronously in any case, I have to
synchronize this scenario. So I think that adding a small thread
control mechanism here (in some kind of a mediator classof course)
would be quite easy and will make the work flow more intuitive and
easier to understand and debug.

Albert