I am considering a design in which in which
select, running in its own thread, sends
"signals" to other threads in which there
there is some heavy number crunching. The
socket is created, and recv takes place in
the number crunching thread. A potential
problem with this is that there might be
excessive delay before recv is executed.

How much of a problem might this be?

If I were to move the recv to the select
thread, what would be the downside there?

Thanks for your advice.
Mike.

Mike - EMAIL IGNORED <m_d_berger_1900@yahoo.com> wrote:
> I am considering a design in which in which select, running in its
> own thread, sends "signals" to other threads in which there there is
> some heavy number crunching. The socket is created, and recv takes
> place in the number crunching thread. A potential problem with this
> is that there might be excessive delay before recv is executed.

You put "signals" in quotes - what is the nature of these signals? I
presume they are not "Unixy" signals?

What leads to the potential excessive delays before the recv? Is the
"signal" not acted upon until the thread has come-out of the heavy
number crunching routing? If so, why not simply have that thread try
a non-blocking recv() on that socket, if something is there, process
it, otherwise, go back and do more number crunching and try again
later.

I suspect that the check the number crunching thread would do to check
for your "signal" may not be all that much better than the
non-blocking recv() call.

> How much of a problem might this be?

> If I were to move the recv to the select thread, what would be the
> downside there?

Can the select/recv thread processes the message? If not, you still
have to communicate to another thread the presence of the message,
which probably means a queue and a condition variable or something -
at least a mutex.

Is there a requirement for a timely "ACK" to the message if not a
completed response?

rick jones
--
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

On Wed, 29 Mar 2006 17:57:43 +0000, Rick Jones wrote:

> Mike - EMAIL IGNORED <m_d_berger_1900@yahoo.com> wrote:
>> I am considering a design in which in which select, running in its
>> own thread, sends "signals" to other threads in which there there is
>> some heavy number crunching. The socket is created, and recv takes
>> place in the number crunching thread. A potential problem with this
>> is that there might be excessive delay before recv is executed.
>
> You put "signals" in quotes - what is the nature of these signals? I
> presume they are not "Unixy" signals?

The "signals" are merely pushes to a queue with mutex and
condition variable you mention below. The condition variable
only fires on a push to an empty queue. Since the processing
alters no externally visible state variables, it is done with
the mutex unlocked.

>
> What leads to the potential excessive delays before the recv? Is the
> "signal" not acted upon until the thread has come-out of the heavy
> number crunching routing? If so, why not simply have that thread try
> a non-blocking recv() on that socket, if something is there, process
> it, otherwise, go back and do more number crunching and try again
> later.

Sounds good. How would I estimate how frequently I should do this?
As I think about this, I am wondering if moving all the recv
calls to the select thread, and send the received data to
the process thread (of course with smart pointer, etc, to
avoid repeated memcpy).

What do you think?

>
> I suspect that the check the number crunching thread would do to check
> for your "signal" may not be all that much better than the
> non-blocking recv() call.

Interesting, but this would preclude use of "signals" from
other threads.

>
>> How much of a problem might this be?
>
>> If I were to move the recv to the select thread, what would be the
>> downside there?
>
> Can the select/recv thread processes the message? If not, you still
> have to communicate to another thread the presence of the message,
> which probably means a queue and a condition variable or something -
> at least a mutex.

As mentioned above, these are the "signals".

>
> Is there a requirement for a timely "ACK" to the message if not a
> completed response?
>

Not unless something about the tcp protocol requires it.
If there were such a need, the processing thread could send
a an application-level ACK.

> rick jones

Thanks again for your ,
Mike.

Mike - EMAIL IGNORED <m_d_berger_1900@yahoo.com> wrote:
>> What leads to the potential excessive delays before the recv? Is the
>> "signal" not acted upon until the thread has come-out of the heavy
>> number crunching routing? If so, why not simply have that thread try
>> a non-blocking recv() on that socket, if something is there, process
>> it, otherwise, go back and do more number crunching and try again
>> later.

> Sounds good. How would I estimate how frequently I should do this?

Presumeably, however often the compute thread(s) check the condition
variable in the existing scheme.

> As I think about this, I am wondering if moving all the recv
> calls to the select thread, and send the received data to
> the process thread (of course with smart pointer, etc, to
> avoid repeated memcpy).

> What do you think?

I think it means that processing the message requires two context
switches when it could just need one if the thread that was going to
process the message was the one to read it (without a select).

Now, if the number of sockets becomes greater than the number of
threads or whatnot, and there is no reasonable way to divvy-up the
sockets among the threads it may indeed be necessary/desirable to
separate things a bit.

>> I suspect that the check the number crunching thread would do to
>> check for your "signal" may not be all that much better than the
>> non-blocking recv() call.

> Interesting, but this would preclude use of "signals" from
> other threads.

If the compute threads have to communicate with one another, if the
communication is sufficiently "rare" perhaps they could communicate
via (non-blocking) sockets themselves. If the communication is more
frequent, then mutexes and condition variables may be more efficient.


>>
>> Is there a requirement for a timely "ACK" to the message if not a
>> completed response?
>>

> Not unless something about the tcp protocol requires it.
> If there were such a need, the processing thread could send
> a an application-level ACK.

That would depend on how long it "processed" before grabbing the
message right? I asked because if the remote needed some sort of
quick reply, then you might indeed want the selecting thread to do the
recv and generate the application-llevel "we're working on it" ACK.

rick jones
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Mike - EMAIL IGNORED wrote:
> I am considering a design in which in which
> select, running in its own thread, sends
> "signals" to other threads in which there
> there is some heavy number crunching. The
> socket is created, and recv takes place in
> the number crunching thread. A potential
> problem with this is that there might be
> excessive delay before recv is executed.
>
> How much of a problem might this be?
>
> If I were to move the recv to the select
> thread, what would be the downside there?
>
> Thanks for your advice.
> Mike.
>
>
If your select thread doesn't actually do the recv(), but just
queues a signal to another thread, then when it goes and
select()s again, there's a good chance it will see the socket is
STILL ready to read, and therefore queue another signal. You
could send up sending a whole stream of signals when just one
packet arrives. I don't like that idea.

So I think you should do the recv() in the selecting thread, and
queue the data instead of just a signal.

Steve

On Sat, 08 Apr 2006 23:04:23 +0100, Steve Horsley wrote:

> Mike - EMAIL IGNORED wrote:
[...]
>>
>>
> If your select thread doesn't actually do the recv(), but just
> queues a signal to another thread, then when it goes and
> select()s again, there's a good chance it will see the socket is
> STILL ready to read, and therefore queue another signal. You
> could send up sending a whole stream of signals when just one
> packet arrives. I don't like that idea.

The select thread doesn't look at a socket that just
read until the read thread "signals" that it has read,
so this is not a decisive argument.

>
> So I think you should do the recv() in the selecting thread, and
> queue the data instead of just a signal.
>
> Steve