rtel wrote on Thursday, December 30, 2004:
> >>Is more like Windoze style thread than RTOS task
> Do You think about WinAPI TerminateThread()?
> Do not ever use it to terminate thread if You want your application to run for
> a long time !!! It breaks thread at the current point of execution and removes
> it from scheduler freeing thread stack. It’s lieke vTaskDelete in FreeRTOS.
Sorry cant comment on WinAPI as its out of my realm.
> Richard: of course. You have right if You are talking about small complexity
> systems. In most cases in embeded systems there are not thread termination at
> >>there is not always a parent thread for example - NO! There is always parent
> thread It may be Root thread (main function is called from its context).
Ok, a question of semantics I suppose.
There are of coarse occasions when one task may create another. There are also those tasks that are created before the kernel has started. These are effectively started from main() and once the kernel has started the context of main() effectively does not exist. It never runs again unless the vPortEndScheduler() is called. I have only vPortEndScheduler() for the ports that run over DOS, because in other cases there is nothing to return to.
> Someone creates thread of course - so it is parent.
> Of course thread can be signaled to terminate by different thread than parent.
There is no super process running in the middle of the kernel that has knowledge of all the message queues. It is up to the application design to say which tasks have knowledge of which threads and how to talk to which threads. There is no automatic way of communicating with a thread unless the threads generates a queue/semaphore/ and gives the rest of the system knowledge of it.
> >>If your tasks can all take this form then this is fine
> Which another form could them take?
A task may never block (like the idle task) but just run continuously in the background.
A task may block on a semaphore. A task may block on a queue. A task may run periodically (very common).
Most of these forms of execution do not require a central messaging system. Of coarse you could create a queue which is checked for signals without blocking every iteration but this will take up a lot of resources and severely limit the amount of tasks that can be created (remember the FreeRTOS is running on 8bit systems with as little as 1.5KBytes of RAM).
> Of course there may be not massage queue and signaling to terminate could look
> like this:
> static volatiole boolean bTerminate = false;
> static void threadFn(void *pParam)
> if(bTerminate == true)
> May I have a question?
> What kind of embeded systems are You designing?
How long have you got? Industrial automation, consumer electronics, motor control, hobby projects, automotive, . a rather general answer I know.
> PS. My name is Kamil -> I think i should register soon to be visible at forum
> not as Nobody
Thanks for your interesting comments.