A question about thread-architecture.

[Sven]

b) here is most important problem: that is that the i/o thread you don't want it to eat a full core. So basically you need to call Sleep there.

I have it sleep 10 milliseconds for example each time. Now that seems fine, except when you want to play super superbullet type games with your engine.

Hi Vincent,

I wonder why you sleep in the I/O thread? I have a plain while ( fgets() ) loop and haven't noticed the I/O thread eat any CPU time. Perhaps you read the input in a different way?
I thought that fgets on stdin should always be blocking...

Martin

Actually I wondered about exactly the same thing. A blocking read does not eat CPU time. Sleep() is not appropriate here IMO.

Sven

You cannot do blocking read of course in the thread that commands the search. A 3d thread is used for that in Diep in its own DEP protocol.

I don't get the meaning of your reply, nor the "of course" in it. In your other reply to Bob you state almost exactly the opposite. So where is the problem you see in my statement? Obviously others, like Bob, have already done exactly what I mentioned (one thread doing a blocking read and one or more threads for searching), and it worked. It requires each searching thread to poll for timeout or external cancellation (the latter issued by the "I/O thread") but both polling for input and actually processing the input is done exclusively by the "I/O thread".

Sven

[bob]

b) here is most important problem: that is that the i/o thread you don't want it to eat a full core. So basically you need to call Sleep there.

I have it sleep 10 milliseconds for example each time. Now that seems fine, except when you want to play super superbullet type games with your engine.

Hi Vincent,

I wonder why you sleep in the I/O thread? I have a plain while ( fgets() ) loop and haven't noticed the I/O thread eat any CPU time. Perhaps you read the input in a different way?
I thought that fgets on stdin should always be blocking...

Martin

Actually I wondered about exactly the same thing. A blocking read does not eat CPU time. Sleep() is not appropriate here IMO.

Sven

You cannot do blocking read of course in the thread that commands the search. A 3d thread is used for that in Diep in its own DEP protocol.

I don't get the meaning of your reply, nor the "of course" in it. In your other reply to Bob you state almost exactly the opposite. So where is the problem you see in my statement? Obviously others, like Bob, have already done exactly what I mentioned (one thread doing a blocking read and one or more threads for searching), and it worked. It requires each searching thread to poll for timeout or external cancellation (the latter issued by the "I/O thread") but both polling for input and actually processing the input is done exclusively by the "I/O thread".

Sven

What we have heah is a failuh ta communicate...

-- warden in "Cool Hand Luke".

I think the model he is talking about is where the search does nothing by itself. It has to be told when to search, when to stop, etc. It doesnt' even handle basic timing decisions. If you do that, the "I/O thread" can't deal with time issues since it is blocked on a read, unless you resort to signals which increases the complexity.

I think that in his model you end up with an I/O thread that is blocked, a timing thread that sleeps, and a search thread (or threads) that are busy searching but don't do any sort of input polling or time checking...

In Cray Blitz I sort of "split the difference." An I/O thread to read input, and a search thread that searched/pondered/did everything but read input. The search thread just checked a flag that said "look at command buffer, you have something to deal with". The search thread also did the usual time checks and "panic time" decisions internally.

I plan to go to a "clean model" in Crafty at some point in time, since we are years beyond the days when we had to ask MSDos to poll the keyboard buffer to check for input characters, with no multi-threading possible...

[diep]

b) here is most important problem: that is that the i/o thread you don't want it to eat a full core. So basically you need to call Sleep there.

I have it sleep 10 milliseconds for example each time. Now that seems fine, except when you want to play super superbullet type games with your engine.

Hi Vincent,

I wonder why you sleep in the I/O thread? I have a plain while ( fgets() ) loop and haven't noticed the I/O thread eat any CPU time. Perhaps you read the input in a different way?
I thought that fgets on stdin should always be blocking...

Martin

Actually I wondered about exactly the same thing. A blocking read does not eat CPU time. Sleep() is not appropriate here IMO.

Sven

You cannot do blocking read of course in the thread that commands the search. A 3d thread is used for that in Diep in its own DEP protocol.

I don't get the meaning of your reply, nor the "of course" in it. In your other reply to Bob you state almost exactly the opposite. So where is the problem you see in my statement? Obviously others, like Bob, have already done exactly what I mentioned (one thread doing a blocking read and one or more threads for searching), and it worked. It requires each searching thread to poll for timeout or external cancellation (the latter issued by the "I/O thread") but both polling for input and actually processing the input is done exclusively by the "I/O thread".

Sven

What we have heah is a failuh ta communicate...
-- warden in "Cool Hand Luke".

Nah we just have a guy who didn't read what i wrote before in replies to this thread. And i wrote it 3 times

I see also one message where i write:

"
It's doing also time division, giving command to start a search etc, just not searching itself.

On top of that a 3d thread is doing a blocked read of stdin or the incoming TCP/IP connection, whichever is appropriate.

You don't want to do any of that in a polling model of course."

[Sven]

b) here is most important problem: that is that the i/o thread you don't want it to eat a full core. So basically you need to call Sleep there.

I have it sleep 10 milliseconds for example each time. Now that seems fine, except when you want to play super superbullet type games with your engine.

Hi Vincent,

I wonder why you sleep in the I/O thread? I have a plain while ( fgets() ) loop and haven't noticed the I/O thread eat any CPU time. Perhaps you read the input in a different way?
I thought that fgets on stdin should always be blocking...

Martin

Actually I wondered about exactly the same thing. A blocking read does not eat CPU time. Sleep() is not appropriate here IMO.

Sven

You cannot do blocking read of course in the thread that commands the search. A 3d thread is used for that in Diep in its own DEP protocol.

I don't get the meaning of your reply, nor the "of course" in it. In your other reply to Bob you state almost exactly the opposite. So where is the problem you see in my statement? Obviously others, like Bob, have already done exactly what I mentioned (one thread doing a blocking read and one or more threads for searching), and it worked. It requires each searching thread to poll for timeout or external cancellation (the latter issued by the "I/O thread") but both polling for input and actually processing the input is done exclusively by the "I/O thread".

Sven

What we have heah is a failuh ta communicate...
-- warden in "Cool Hand Luke".

Nah we just have a guy who didn't read what i wrote before in replies to this thread. And i wrote it 3 times

I see also one message where i write:

"
It's doing also time division, giving command to start a search etc, just not searching itself.

On top of that a 3d thread is doing a blocked read of stdin or the incoming TCP/IP connection, whichever is appropriate.

You don't want to do any of that in a polling model of course."

I perfectly understood what you did since I DID read what you wrote. It was just that single sentence "You cannot do blocking read of course in the thread that commands the search." in your reply to me that didn't make sense to me. But maybe I should have written it like this: "Your statement is valid for Diep but not for the general case." It is certainly possible to have a different thread architecture than the one in Diep.

Sven