To queue or not to queue

Hey group, I recently started a new job where the target is a handheld device with 3 buttons on it and a few other internal interrupts, occurring maybe only every 125ms when it is in a real processing mode, with little processing to do to service the interrupts. The system runs on a low power controller and goes to low power mode whenever possible. It is implemented as a state machine, with a bunch of sub-states, so it is really a single threaded application. This was initially designed and implemented maybe 20 yrs ago, and ported over the years.

But, the exisiting design has an event queue. I do not understand why for such a simple system. The ISRs log the events, the main operating loop queues the events to itself, and then deques and makes calls into the appropriate sub-state machine. I want to lobby to get rid of this queue because the system really cannot process more than one event at a time anyway, and the events are so spread out over time.

I contend that the single threaded application should be permitted to run as far as it can before needed an event, at which point it could simply go into low power mode and wait for an event that concerns it to wake the system. The ISR could log what the event was, if pertinent for that state, and wake the processor to handle it.

Now I have tried this arguement with co-workers already; of course I am new here and this is their baby, and everyone is resistent to change. Removal of the queue would significantly simplify the already simple system. Even state changes, state changes not even caused by events, are queued!

I guess what I am looking for is some documented ammunition for my superiors and co-workers that states when use of queue is desirable and when it is overkill. Any good books journals out there?

Reply to
Ivanna Pee
Loading thread data ...

Have I got this right, it's been a working product for 20 years and you want to change it because it's generality offends your sensibilities?


Posted via a free Usenet account from
Reply to
Robert Adsett

The way i see it. Thye have ported many times, but never really refactored... That is saying something about the company.

HOWEVER, if it is simply legacy support for an old product, the who really cares. Leave it alone. Why are you in the code? What are the business reasons for you to be in the code.What are you trying to acheive?

Reply to
The Real Andy

Having a queue between two asynchronous processes (in this case the interrupt and your main loop) is always a good idea. The system may be very simple and not really needing that, but in the future it may evolve to a more complex one and you will not have to worry about queueing events. It is much safer to have that queue. Unless you have some immediate advantage from taking it off (like reducing the cost or solving speed issues), leave it there.

Reply to

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.