Re: Threading - Is this Ok?

Tech-Archive recommends: Fix windows errors by optimizing your registry

On 7 фев, 21:00, "richard.markiew...@xxxxxxxxxxxx"
<richard.markiew...@xxxxxxxxxxxx> wrote:
On Feb 7, 11:32 am, Sergey Zyuzin <forever....@xxxxxxxxx> wrote:





On Feb 7, 4:48 pm, "richard.markiew...@xxxxxxxxxxxx"

<richard.markiew...@xxxxxxxxxxxx> wrote:
Hi,

I'm developing a custom web part (basically an ASP web control in a
fancy wrapper if you're not familiar), something which I've done
several times before. However this one is a little different, as it
exists on a page and when the user presses a button, has to do a long
running operation. I want the page to still be interactive in this
time, with the web part showing status updates until it's finished.

So - I've implemented the Microsoft AJAX controls to allow me to
refresh just the web part when I need to update it. I can update the
panel using a Timer control. Now I need to do the actual work - and to
do that I believe the only way is to spin the work out into a separate
thread? I've never worked with threading before, and am anxious about
ending up thedailywtf.com. My requirements are very simple - just a
single thread to do the work in the background.

So - I was hoping someone with more experience might look over what
I've got and tell me if I'm on the right lines, or heading for a fall:

        System.Web.UI.Timer myTimer = new System.Web.UI.Timer();
        Thread threadObj;
        private static string Status = "";

        private void HandleButtonClick(object sender, EventArgs
eventArgs)
        {
            Page.Validate();
            if (Page.IsValid)//Do some validation on the information
entered
            {
                myTimer.Enabled = true;
                threadObj = new Thread(new
ThreadStart(LongRunningProcess));
                threadObj.Start();
            }
        }

        void myTimer_Tick(object sender, EventArgs e)
        {
            if ((Status == "Error") || (Status == "Finished"))
            {
                T.Enabled = false;
            }
        }

        private void LongRunningProcess()
        {
            try
            {
                //Do some work that's going to take a while, call some
other classes/methods
                Status = "Finished that bit of work";
                //Do some work that's going to take a while, call some
other classes/methods
                Status = "Finished";
            }
            catch (Exception ex)
            {
                Status = "Error";
            }
        }

Is it appropriate to use a thread in this scenario? Is it appropriate
for me set a "status" in my long running process, and then poll that
status using a timer every few seconds? Do I need to be doing anything
else with my thread when it's finished, or when it errors?

Many many thanks in advance, Richard

I'm not sure I understand how it's going to work. I didn't work with
Microsoft AJAX,
but the timer runs on server and it will fire when the page is already
sent to client. So client will not see any progress. I think there
should be a timer on the client side (in browser) which will cause
requests to server to refresh progress.

Also I wouldn't start a thread in page handler that is not going to
finish until request finishes. 100 clients can cause 100 threads
running simultaneously. I would rather create a queue somewhere (MSMQ,
SQL Server or smth). Page handler would put tasks in this queue and
some Windows Service would process them, periodically reporting
status.

HTH,
Sergey

Thanks Sergey.

The timer stuff basically works, because it's an AJAX update panel
that gets updated when the timer ticks - it's not the whole page
getting refreshed.

To simplify the problem, forgetting the AJAX stuff. Maybe this is more
of an ASP.NET question than a C# language question.

The control will be used by 1, maybe 2 users at a time. The long
running code takes maybe 10 seconds to execute (long enough that I
need to do something to keep the app responsive, or the user thinks it
has crashed). But let's be pessimistic and say I'll have 100
simultaneous users and the code takes 100 seconds to execute.

What are the disadvantages of 100 clients causing 100 threads to run
simultaneously? Is it just a performance thing? Or am I heading for a
crash? Is there a limit on the number of threads I can run
simultaneously?

If an exception occurs in my thread, do I need to do anything special,
any cleaning up after myself? Or when the thread finishes or hits an
unhandled exception, does it just shut down?

If one has a long running process going in a separate thread, and
needs to check the status of it every few seconds, or determine when
it's finished, what's the best way to do that? Is it appropriate for
me to poll a thread for a "status" value? Or is there some native way
to do this that I'm missing?

Many thanks again,

Richard- Скрыть цитируемый текст -

- Показать цитируемый текст -

Hi, Richard,
I see now, System.Web.UI.Timer is a client timer (I've learned a bit
of Microsoft AJAX now :))

If you have lots of threads running long operations most likely your
server will be very busy serving them and
won't be able to process requests from other users quickly (however
that depends on what and how threads do).
Having 100 threads processing 100 tasks can appear to be slower than 2
threads processing the same 100 tasks consequently.
(But that's again depends). There's also some performance/memory
overhead on creating threads, so often a thread pool
is used instead.

I was talking about large scale applications, so if you have few
users, you don't have a web farm you can probably use threads inside
ASP.net process to execute long running task, as you do (also this
seems a little unusual to me. Maybe you'd better ask in ASP.NET
forums)

You need to handle exceptions in your threads, otherwise web server
process may crash.

For status you can not use that static variable. If you have 2 users
that will start two threads, then both threads will write to the same
variable.
I think you can put Status into Session state and pass Session to a
thread so it updates Status as needed (if you don't store Session in
database or another computer). When timer fires you can get Status
back from Session and send it back to user. Session is not thread-
safe, so you might need to lock when accessing it.

HTH,
Sergey
.

Quantcast