Threading Advice

  • Thread starter Thread starter melton9
  • Start date Start date
M

melton9

I have a web service that I believe needs to implement threading. I
have a timer setup to fire 3 requests and have them do some
calculations and send the info to the mainform. I also need the click
events on the mainform remain in real time. Through a little
experimentation it seems that I can only use 1 sub to update the form
to avoid cross threading. So maybe have the timer fire the 3 requests
and then when they are complete fire the sub to update the form. Can
anyone help point me in the right direction here?

Timer>>>3 requests>>>sub to update mainform
While keeping the mainform clicks in real time.

Thanks a lot.
 
Melton,

How many threads you think there will be active and keep than in mind that
every user is running on its own thread? Are you not afraid that you will
quickly reach the maximum?

Cor
 
Sorry, I think I misspoke. I am building an app on the user side to
access a webservice. I think I've figured out how to run the form
separately using BeginInvoke, but I still haven't solved the requests.
Is it even possible to send 3 at the same time or will it run 1 then
the next etc? It takes about 500ms to recieve the response and
process. So if I were able to manage to send all 3 requests at the
same time then I would probably have to put a thread.sleep(600) on the
ui update thread. Otherwise its going to take about 1.5 seconds to run
all 3 in line.

Any ideas? If I have to run them in line then I will, but I would
rather try and speed this up.
 
A webservice is multithreaded by design , this is taken care of by the
hosting process ( IIS )
i.ow if you multithread your client app and call a service 3 times call 2
might be sooner finished as call 1 ( or it might not )

if this is not a problem for you , you might encapsulate your calls in a
class with an id
to track wich call is fired and returned

about the UI update thingy

read the invokerequired property of the control you want to update if it is
true you need to recall the updating procedure with a delegate to
synchronize the thread


regards

Michel Posseth [MCP]
 
Melton,

Don't expect that with threading you can speed up processes which have a
serial botleneck.

There cannot go more water through a pipe than its through its smallest
part.

The same is with data. Now your process takes 1.5ms. With the threads it
will take probably more just because that the throughput is interupted and
that your webservice is probably handling more users in a sequential way,
therefore you have introduced extra waittimes.

Your smallest part is not widened up by threading. (Or you should have
different independent working webservice on more locations).

Just my thought,

Cor
 
IMHO in a server based architecture this is not the case Cor and i believe
that is where the TS is talking about

With SOA designs this is exact one of the few situations were multithreading
really can give you a performance benefit

regards

Michel Posseth [MCP]
 
Mischel,

Describe where I am in your opinion wrong.

Suppose I want 1000 parts of data.
I get this from a server over whatever line.
The bottleneck is mostly the line but can be of course somewhere else
Suppose I create 1000 threads to get everytime 1 piece of data.

Where is than my benefit because the data has sequential to pass the
smallest part of the pipeline (Can be by instance as well the processing
ability (speed etc) of the Server).

I know situations where it can be benefited beside what I wrote already if
there are more suppliers.

That is where there are supporting more connections per user but where the
maximum throughput per connection is limited by a certain bandwidth. Because
that stupid situation has everybody made multithreading programs for that.
Therefore I assume that in those cases in future that the connections will
be limited per user. As sample this is the fact by downloadaccelarators (As
they are using more downloadservers than it is fine, than they fall in the
category I have described in my first message).

But from what was written I had not the idea that it was about such a kind
of downloadaccelarator.

Cor


Michel Posseth said:
IMHO in a server based architecture this is not the case Cor and i believe
that is where the TS is talking about

With SOA designs this is exact one of the few situations were
multithreading really can give you a performance benefit

regards

Michel Posseth [MCP]





Cor Ligthert said:
Melton,

Don't expect that with threading you can speed up processes which have a
serial botleneck.

There cannot go more water through a pipe than its through its smallest
part.

The same is with data. Now your process takes 1.5ms. With the threads it
will take probably more just because that the throughput is interupted
and that your webservice is probably handling more users in a sequential
way, therefore you have introduced extra waittimes.

Your smallest part is not widened up by threading. (Or you should have
different independent working webservice on more locations).

Just my thought,

Cor
Click to expand...
Click to expand...
 
Well in your described situation it is indeed foolish to use multithreading
( if it is only about static data retrieval )

However what if the business logic is on the server ? ( as it is more and
more the case nowadays , thanks to webservices , remoting and COM+
architecture )

Instead of waiting for a transaction to finish you could already send or
process another piece of information
even better a "Good" programmer starts the longest running task first and
then starts all subsequent tasks in order of longest running time
in a ideal situation the total processing time on the client is now the time
of the longest running process while in a single threaded architecture
the total processing time is at least the sum of all tasks.

But indeed "most" people use multithreading / asynchronous processing in a
bad way and forget that one person running 100 meters is almost ever faster
as 10 persons running 10 meters , but as i said in some situations the
opposite is true let say we talk now about 50.000 meters who is now faster
?? ( unless he comes from Kenia or Ethiopia :-) .

So in the end it all comes down in rightly defining the solution`s
architecture



regards

Michel Posseth [MCP]







Cor Ligthert said:
Mischel,

Describe where I am in your opinion wrong.

Suppose I want 1000 parts of data.
I get this from a server over whatever line.
The bottleneck is mostly the line but can be of course somewhere else
Suppose I create 1000 threads to get everytime 1 piece of data.

Where is than my benefit because the data has sequential to pass the
smallest part of the pipeline (Can be by instance as well the processing
ability (speed etc) of the Server).

I know situations where it can be benefited beside what I wrote already if
there are more suppliers.

That is where there are supporting more connections per user but where the
maximum throughput per connection is limited by a certain bandwidth.
Because that stupid situation has everybody made multithreading programs
for that. Therefore I assume that in those cases in future that the
connections will be limited per user. As sample this is the fact by
downloadaccelarators (As they are using more downloadservers than it is
fine, than they fall in the category I have described in my first
message).

But from what was written I had not the idea that it was about such a kind
of downloadaccelarator.

Cor


Michel Posseth said:
IMHO in a server based architecture this is not the case Cor and i
believe that is where the TS is talking about

With SOA designs this is exact one of the few situations were
multithreading really can give you a performance benefit

regards

Michel Posseth [MCP]





Cor Ligthert said:
Melton,

Don't expect that with threading you can speed up processes which have a
serial botleneck.

There cannot go more water through a pipe than its through its smallest
part.

The same is with data. Now your process takes 1.5ms. With the threads it
will take probably more just because that the throughput is interupted
and that your webservice is probably handling more users in a sequential
way, therefore you have introduced extra waittimes.

Your smallest part is not widened up by threading. (Or you should have
different independent working webservice on more locations).

Just my thought,

Cor

<[email protected]> schreef in bericht
Sorry, I think I misspoke. I am building an app on the user side to
access a webservice. I think I've figured out how to run the form
separately using BeginInvoke, but I still haven't solved the requests.
Is it even possible to send 3 at the same time or will it run 1 then
the next etc? It takes about 500ms to recieve the response and
process. So if I were able to manage to send all 3 requests at the
same time then I would probably have to put a thread.sleep(600) on the
ui update thread. Otherwise its going to take about 1.5 seconds to run
all 3 in line.

Any ideas? If I have to run them in line then I will, but I would
rather try and speed this up.
Click to expand...
Click to expand...
Click to expand...
 
Back
Top