Similar thread issues

I'm having
I have a UI, and a second, comms, thread that will be simply looping and sending and recieving data to RS232 as frequently as possible.
I'm struggling to figure the best way to have the data shared between the threads so the user can enter new co-ordinates in the UI and it will process the change and alter the data that the comms thread reads, in a fashion that gives the required acceleration and speed of movement of the item.

I'm wondering if it would be better to use some sort of a stack of co-ords (co-ords are actually in a 23 byte string) written in one go by the UI thread, and picked off one at a time by the comms thread (down to the final position at which it will continue sending that position)instead of an intensive UI thread, bearing in mind that the other end of the RS232 is sat expecting constant data feed with no more than 250ms between new co-ords.

I'm guessing I'm using CS's too which dont appear to be a prob on the surface. I'm hoping not anyway!

My backgroud = new to programming so go easy :)



  • That actually is a very good idea...except one thing. Since this is a time critical operation (need info every 250s) then you need to inhibit the thread that sends the data as little as possible. This is all a design issue I think.

    When the UI locks the cs (yes, you'll need it with the queue idea) then the other thread can't run until the UI unlocks it. This could put you over 250 limit. Messages might be even worse (they use the queue structure as well).

    My only idea is to do some tests. Run several scenarios (sorry to make you code more than one) and put in some timers. Normal windows timers have on average a percision of 50, less than your 250. If the thing goes over the limit alert yourself. The one that alerts the fewest is the winner.

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


In this Discussion