ThreadPool

  • Thread starter Thread starter John
  • Start date Start date
J

John

Is there a way to know the name (or hashcode) of the thread that will
be used by ThreadPool.QueueUserWorkItem ?

The reason for that is that i want to update clients with ordered data.
I mean that when i send some info to client A (say '1'), i do not want
to send it anoter info (say '2') until i'm sure it received the first
one.

However this could easily occur in the Threapool and to prevent this i
would block sending client A info until its threads is dead

Thanks
 
John,

I don't think that knowing the id of the thread that will be used by
QueueUserWorkItem will help in this situation. Rather, you should have a
class that handles all of this interaction for you. What you would do is
have a method on that class which will accept which messages to send. Then,
in a background thread, that instance of the class will send out the
messages in the ordered manner you want, and wait for the response. When
the acknowledgement is sent back, you can send the next message in the
queue.

It's much better than trying to get threads to execute in a proper
order.

Hope this helps.
 
Nicholas

The problem is that i'm working in a very high data update rate and if
i wait for the answer of the client, i'll be killed.

I've tried Asynchronous delegate and it's too slow.
So i decided to use an Interface : each time i have a message i call
the client method with the data as a parameter :
ThreadPool.QueueUserWorkItem (mymethod,obejct)

The question is how in this situation will i know that this client has
consumed its data so i can continue on sending next data

Thanks
John
 
John,

Because you don't know how long you will have to wait, that's exactly
why you ^can't^ use the thread pool here. The thread pool is intended to be
used for short running operations.

Basically, what I am recommending is that you have two concurrent
operations. It would seem that you already have code which is determining
the messages that need to be sent. Instead of sending them to
QueueUserWorkItem, send them to a manager whose sole purpose is to send
these messages and receive the responses (which would fire an event when you
get a response). The manager would have an internal queue which is
populated when you make the call (you would make this call where you are
currently calling QueueUserWorkItem). The manager would be responsible for
running another thread whose sole purpose is to send the messages (in order)
and wait for a response. When the message is returned, it would then send
out a notification that you can react to.

This is a classic producer/consumer pattern. For more information on
it, check out the following link (watch for line wrap):

http://zone.ni.com/devzone/conceptd.nsf/webmain/C54BADADD8BBDE4286256C5200533B80?opendocument

From the section titled "Why use Producer/Consumer?", it states:

The Producer/Consumer pattern gives you the ability to easily handle
multiple processes at the same time while iterating at individual rates.

This is exactly what you have here (with the message response time being
the main factor).
 
Thanks Nicholas

I'm working on that but i still do not understand something.

The so called manager will quickly be overwhelmed bacause i have more
thant 1000 clients.

That's why i believed a threadpool would be right : to send to 1000
clients quickly

As i understand what you say and agree this issue is still unclear.

My first thought was to use Asynchronous delagates so i can very
quickly send the data and go to the next client
 
John,

The manager is nothing more than a queue (like the thread pool) and the
code that will send messages from the queue and receive responses. When you
create the manager, it will create a new thread which will constantly try
and send messages from the queue and wait for a response. Once you have a
response, you take the next message from the queue, and send that. If there
are no messages, you wait. The key here is that the messages are being sent
on another thread that you create from the mananger.

You won't be overwhelming the class. Your call to add the message to
the queue will do nothing more than insert a message into the queue, and
then notify the thread that it can process the queue (if it is not doing so
already).

You can't control the ordering of the execution of the threads in the
threadpool, which is why you need something like this. Technically, you
could try, but if you are sending thousands of messages, and you are
actually holding up your thread pool in order to maintain ordering, you are
going to quickly starve the thread pool and bring your application to a lock
(there are many areas in the framework where the ThreadPool is used).
 
Yes, but the thread responsbile for the update can be blocked by the
client so i'll need many threads.
Is that true ? And who is responsible to create and kill them ?

My belief was the threadpool...
 
John,

You only need one thread. This is because you stated you need to send
the messages in order and that you could not send another message until you
know the client received the first one. The best way to do this is to send
the messages in sequence, in a single thread. Just have that thread be
separate from the thread that adds the messages that you are going to send.
 
Back
Top