Thread: Semaphores, OS tasks

  1. #1
    Registered User Rennor's Avatar
    Join Date
    Aug 2006
    Location
    Finland
    Posts
    45

    Semaphores, OS tasks

    I was wondering if any of you would know some links to learn more about OS tasks and semaphores (more or less concerning uC/OS-II realtime kernel. I want to create a task which I could start by posting a semaphore.

    In theory this is what I am after:
    Code:
    static int foo_Task( void );
    static os_event *foo_Task_Sem;
    int StartFooTask( void );
    
    int foo_Init()
    {
    	foo_Task(); // OSTaskCreate() should be called instead of calling the function?
    	return 0;
    }
    
    int foo_Task()
    {
    	for(;;)
    	{
    		os_semaphore_pend( foo_Task_Sem );
    		
    		// Do the task here
    	}
    }
    
    int StartFooTask( void ) 
    {
    	os_semaphore_post( foo_Task_Sem );
    	return 0;
    }
    I would, ofcourse, write functions os_semaphore_pend() and os_semaphore_post() myself to add some own checks in it.
    Anyway, above code does not work, since code execution will end up in forever loop in foo_Task() function.

    I read about OSTaskCreate() and I figure that's what I need to call to create a task which would be foo_Task() then. Am I right? Will OSTaskCreate() actually call the function and leave it running behind? (that's how I understood it).

    I would really appreciate some help or any information about resources / links to details about OS tasks and semaphores.

    Thanks
    - Rennor

  2. #2
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > Will OSTaskCreate() actually call the function and leave it running behind?
    Not really. It will create a new task, allocate a stack for the new task, and add the task to the list of tasks that are known to the OS.
    The first call to foo_Task() would appear to come from nowhere because the calling function is really the OS Scheduler calling the function with the freshly created stack.

    In Unix terms, the nearest equivalent is the fork()/exec() sequence. At the end of it, there is a new separate process running which has little to do with the process which started it. One notable thing is that Unix has process heirarchies (parent/child) relationships.

    Most real time operating systems just have a flat list of tasks.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  3. #3
    Registered User Rennor's Avatar
    Join Date
    Aug 2006
    Location
    Finland
    Posts
    45
    Ok, so I am in right tracks then I think. It's just that knowing exactly what happens seems to be essential for me to go on.

    I found this book "MicroC/OS-II The Real-Time Kernel, Second Edition" by Jean J. Labrosse. (CmpBooks). Cant wait to receive that one

    So, Task Scheduler is part of OS which duty is to execute tasks. Ok. And OSTaskCreate() takes argument for priority which defines the order in which the tasks are executed (or which task will be next to run). Now, if I make my task not infinite loop, it executes once and "that's it"?

    Previously I thought I make it infinite loop to make it semaphore triggered, but that seems to be the common practice with tasks.

  4. #4
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    Sounds about right to me.

    Most embedded OS tasks (as most services and daemons on desktops) run as infinite loops with some kind of wait for the next input to go do something.

    And if your task runs just once, it's return will get caught by some code which calls the OS delete task function, and it will duly disappear from the task list.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  5. #5
    Registered User Rennor's Avatar
    Join Date
    Aug 2006
    Location
    Finland
    Posts
    45
    Thanks Salem

    Now all I need is to crack the nut about figuring how much stack I should allocate for my task. Guess I can calculate stack needs by following all the function calls in the task. For some reason I wouldnt like to go with "allocate enough stack" since the device might not have too much memory to spare.

  6. #6
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    Some embedded OS have diagnostic tools to tell you how much stack a task has needed "so far".
    So allocating "enough", then running for a while, then picking a tuned size is a reasonable way to go.

    Go with as much as you can spare during development, since stack overruns are pretty weird things to debug. If stacks are consecutive in memory, and T1 overruns into T2, then it's usually T2 which dies for no reason which makes any kind of sense
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  7. #7
    Registered User Rennor's Avatar
    Join Date
    Aug 2006
    Location
    Finland
    Posts
    45
    Yeah, youre right. I received the book today already.

    uC/OS-II has function OSTaskStkChk() function which provides me with this information.

    It's just that I need to dig deeper into whole concept of tasks to find out the stack use since the task needs to be created with OSTaskCreateExt(). OSTaskCreateExt() is given stack pointer and bottom of it as argument, so OS knows how much stack the task has. By filling the stack with zeros before creating task, OSTaskStkChk() can be called to calculate how much stack was used.

    What OSTaskStkChk() does is loop from stack bottom towards stack start address untill nonzero value is found. Pretty simple Yeah, stack bottom is the end of it... stack in uC/OS-II appears to be from high memory address towards lower memory address. My guess is that there's pretty good reason for that

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Semaphores, need advice on implementation.
    By Swerve in forum C++ Programming
    Replies: 2
    Last Post: 01-13-2009, 01:54 AM
  2. semaphores
    By Dr Spud in forum C Programming
    Replies: 7
    Last Post: 09-22-2007, 12:45 PM
  3. Semaphores Problems
    By mhelal in forum Linux Programming
    Replies: 2
    Last Post: 05-06-2007, 10:36 PM
  4. Detecting if OS is Windows???
    By Ktulu in forum Windows Programming
    Replies: 2
    Last Post: 11-19-2006, 02:49 AM
  5. a simple OS
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 8
    Last Post: 06-06-2004, 10:47 PM