Re: Thread Pre-Emption Question . . .

m wrote:
BTW: Running successfully does not _prove_ anything about the correctness of a piece of software. It does demonstrate that any errors have low (possibly zero) occurrence probability within the operating environment.

Of course, but one to say our critsect.h classes is the premise for flawed code, is false. And I think that I should know our products and its long time usage it the market place by thousands of corporate companies under 365x34x7 operations who after 12 years, BY now would of produce errors related to critsect.h simple b because this is a fundamental critical concept for the product RPC client/server muilt-threaded operations. This is simply not the case. critsect.h is fine.

That being said, I have not reviewed you code in detail; but it does seem odd. And it is defiantly possible to construct a shared read, exclusive write lock that allows acquisition of a read lock without always calling WFXO.

Read the code and the original OP needs. My suggestion for a solution.

He needs a FAST THREAD that works under 40ms.

The suggestion is to queue up data for the signaling to this thread and allow a 2nd or multiple threads to process the queue.

The example code is a MULTIPLE WRITER, SINGLE READER design, and the READER/WRITER logic is fine.

However, as noted, if there is a need for multiple readers, maybe because the queue is building up too fast, then absolutely, a sync on the reading is required.

As to the OP's problem (if he's even still listening): In general, one can't know what is happening during a time when your thread(s) aren't running - if you think about this, then it will become clear why Windows is not a RTOS and why your task, unless it is a debugging / tuning process, is not possible without OS / hardware support.

Windows is not a RTOS because it can not provide the #1 fundamental rule in a RTOS - constant residence time for all threads. That is the basic definition of a RTOS - equal time slicing.

Thanks for your comments.

--
HLS
.

Relevant Pages

  • RE: single-reader/ multiple-writers message queuing
    ... The OS message queues support multiple writes and a single reader. ... - The reader creates the message queue. ... you can have writer threads block until ...
    (microsoft.public.windowsce.app.development)
  • Re: So... What are the alternatives? Was: I dont use an RTOS because...
    ... I have never heard an RTOS having ... reasons that another poster recommended using multiple processors: ... provides most, of the common layer as OS calls, IPC ... there are embedded systems and there are ...
    (comp.arch.embedded)
  • Re: Dumb RTOS Question
    ... until something shows up in the queue. ... to have this process check several "queues" and then suspend for a ... You should match your RTOS to your problem, ... The purpose of an RTOS is to guarantee that something can be ...
    (comp.arch.embedded)
  • Re: Dumb RTOS Question
    ... shows up in the queue. ... an option to work like a ring buffer but that does not seem to be the ... and I'm thinking that you need to go digging for a basic tutorial on using an RTOS. ... using a queue here -- just set a semaphore from your timer ...
    (comp.arch.embedded)
  • Re: Dumb RTOS Question
    ... interprocess communications. ... shows up in the queue. ... I thought a message queue would work or have ... if you have one RTOS task that's performing multiple ...
    (comp.arch.embedded)