Changes between Version 3 and Version 4 of ppc_prog_overview/xilkernel


Ignore:
Timestamp:
Mar 14, 2007, 12:25:59 AM (17 years ago)
Author:
snovich
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ppc_prog_overview/xilkernel

    v3 v4  
    2020Threading is a required component of Xilkernel – at least one thread is required to spawn from the system at kernel start. The main threads are simply functions of type void* and do not take any inputs. The launch threads are defined in SPS under the “'''OS and Libraries Tab''',” under the “'''config_pthread_support'''” header, and finally in the “'''static_pthread_table'''.” A priority level may be given to the thread if priority-scheduling is used in the system – otherwise it will be ignored.[[BR]][[BR]]
    2121There are two scheduling modes in xilkernel: SCHED_PRIO and SCHED_RR, which are also chosen in SPS. SCHED_PRIO is priority based scheduling, in which lower priority threads will always yield to higher priority threads (designated by lower priority numbers), until the higher priority thread finishes or pthread-joining is used. If two threads have the same priority, they will be processed concurrently in round-robin based scheduling. Thus, SCHED_RR is round-robin-based scheduling and is a more simplified form of SCHED_PRIO, in which all threads must be processed at close-to the same time. The human perception of this is that the threads are running in parallel. [[BR]][[BR]]
    22 The pthread support also provides some more advanced functionality such as thread-joining. If a thread is joined with another thread, the caller will pause and wait until the called thread finishes its task. The threading API may be found in “'''$EDK\doc\oslib_rm.pdf'''.” Threading reference designs may be found [http://warp.rice.edu/trac/browser/RefDesigns/WARP_v_1_1/Xilkernel_pthreads_PRIO_ex_for_WARP_v_1_1_XPS8.zip here (SCHED_PRIO)] and [http://warp.rice.edu/trac/browser/RefDesigns/WARP_v_1_1/Xilkernel_pthreads_RR_ex_for_WARP_v_1_1_XPS8.zip here (SCHED_RR)]. The following are some of the common or more important functions involved in threading:
     22The pthread support also provides some more advanced functionality such as thread-joining. If a thread is joined with another thread, the caller will pause and wait until the called thread finishes its task. The threading API may be found in “'''$EDK\doc\oslib_rm.pdf'''.” Threading reference designs may be found [http://warp.rice.edu/trac/attachment/wiki/xilkernel_ref/files/Xilkernel_pthreads_PRIO_ex_for_WARP_v_1_1_XPS8.zip?format=raw here (SCHED_PRIO)] and [http://warp.rice.edu/trac/attachment/wiki/xilkernel_ref/files/Xilkernel_pthreads_RR_ex_for_WARP_v_1_1_XPS8.zip?format=raw here (SCHED_RR)]. The following are some of the common or more important functions involved in threading:
    2323
    2424 * '''pthread_create( )''' – this function generates and starts a thread running, given a thread identifier name, an attribute structure, a function name (the process itself), and arguments for the function if any are needed.
     
    3030== Mutex ==
    3131
    32 Mutex is short for “mutual exclusion lock.” These are a very simple form of semaphore. In xilkernel, a thread may create a mutex (in either a locked or unlocked state). If the calling thread puts it in a locked state, that thread will have the lock. Otherwise, the first thread to call the locking function will get it. Any time a thread in the system attempts to lock an already-locked mutex, the thread will pause it’s processing until the lock becomes available. This is a very simple tool for controlling access to a resource (such memory or a GPIO peripheral). The mutex API may be found in “'''$EDK\doc\oslib_rm.pdf'''.” A mutex reference design for WARP may be found [http://warp.rice.edu/trac/browser/RefDesigns/WARP_v_1_1/Xilkernel_mutex_ex_for_WARP_v_1_1_XPS8.zip here].The following are some of the common or more important functions involved in mutex use:
     32Mutex is short for “mutual exclusion lock.” These are a very simple form of semaphore. In xilkernel, a thread may create a mutex (in either a locked or unlocked state). If the calling thread puts it in a locked state, that thread will have the lock. Otherwise, the first thread to call the locking function will get it. Any time a thread in the system attempts to lock an already-locked mutex, the thread will pause it’s processing until the lock becomes available. This is a very simple tool for controlling access to a resource (such memory or a GPIO peripheral). The mutex API may be found in “'''$EDK\doc\oslib_rm.pdf'''.” A mutex reference design for WARP may be found [http://warp.rice.edu/trac/attachment/wiki/xilkernel_ref/files/Xilkernel_mutex_ex_for_WARP_v_1_1_XPS8.zip?format=raw here].The following are some of the common or more important functions involved in mutex use:
    3333 * '''pthread_mutex_init( )''' – this function generates a controllable mutex given a mutex ID and  mutex attribute structure.
    3434 * '''pthread_mutex_lock( )''' – this function will give the calling thread a lock on the mutex if it is available. Otherwise, the thread will suspend execution until the mutex is freed by the other process.
     
    3939== Semaphores ==
    4040
    41 Semaphores are very similar to mutecies, but provide extra functionality. Semaphores can be given string names; they contain “counting” information, which can be used to tell how many threads it is blocking; they also provide more advanced waiting (locking) functions such as timed-waiting. The semaphore functions are also utilized in higher-level memory management such as xilkernel’s message queues. The semaphore API may be found in “'''$EDK\doc\oslib_rm.pdf'''.” A semaphore reference design for WARP may be found [http://warp.rice.edu/trac/browser/RefDesigns/WARP_v_1_1/Xilkernel_semaphores_ex_for_WARP_v_1_1_XPS8.zip here]. The following are some of the common or more important functions involved in semaphore use:
     41Semaphores are very similar to mutecies, but provide extra functionality. Semaphores can be given string names; they contain “counting” information, which can be used to tell how many threads it is blocking; they also provide more advanced waiting (locking) functions such as timed-waiting. The semaphore functions are also utilized in higher-level memory management such as xilkernel’s message queues. The semaphore API may be found in “'''$EDK\doc\oslib_rm.pdf'''.” A semaphore reference design for WARP may be found [http://warp.rice.edu/trac/attachment/wiki/xilkernel_ref/files/Xilkernel_semaphores_ex_for_WARP_v_1_1_XPS8.zip?format=raw here]. The following are some of the common or more important functions involved in semaphore use:
    4242
    4343 * '''sem_init( )''' – this function generates an unnamed semaphore given a pre-defined semaphore ID. The function also allows the semaphore to be placed in a locked state (a count value greater than or equal to 1) or an unlocked state (a count value of 0).
     
    4848== Shared Memory ==
    4949
    50 The shared memory functionality is still under development by Xilinx. In its current state, it is a weaker version of a locking mechanism as it does not provide any thread blocking/freezing features (there is no waiting functionality). Instead, the shared memory locking mechanism is just a counter for the number of threads that are attached to the shared memory. The convenience of shared memory, is that it can be used to allocate a buffer of custom size, and return the buffer’s base address upon a successful attach call. The shared memory API may be found in “'''$EDK\doc\oslib_rm.pdf'''.” A shared memory reference design me be found [http://warp.rice.edu/trac/browser/RefDesigns/WARP_v_1_1/Xilkernel_shmem_ex_for_WARP_v_1_1_XPS8.zip here]. '''Note''': The detach function in the documentation is listed as “shm_dt,” but should be “shmdt.” The following are some of the common or more important functions involved in using shared memory:
     50The shared memory functionality is still under development by Xilinx. In its current state, it is a weaker version of a locking mechanism as it does not provide any thread blocking/freezing features (there is no waiting functionality). Instead, the shared memory locking mechanism is just a counter for the number of threads that are attached to the shared memory. The convenience of shared memory, is that it can be used to allocate a buffer of custom size, and return the buffer’s base address upon a successful attach call. The shared memory API may be found in “'''$EDK\doc\oslib_rm.pdf'''.” A shared memory reference design me be found [http://warp.rice.edu/trac/attachment/wiki/xilkernel_ref/files/Xilkernel_shmem_ex_for_WARP_v_1_1_XPS8.zip?format=raw here]. '''Note''': The detach function in the documentation is listed as “shm_dt,” but should be “shmdt.” The following are some of the common or more important functions involved in using shared memory:
    5151
    5252 * '''shmget( )''' – given a request for a size of memory space, the function will return an integer ID for the shared memory region upon success.
     
    5757== Dynamic Memory ==
    5858
    59 Xilkernel’s dynamic memory functions are used for allocating buffers of custom sizes and widths. The buffers are made from a preset memory table located in the “'''OS and Libraries'''” section of “'''Software Platform Settings'''.”  This functionality is useful for creating a buffer repository for memory structures of custom size – such as a packet. The dynamic memory allocation functions provide no resource-locking mechanisms, however. Dynamic memory API may be found in “'''$EDK\doc\oslib_rm.pdf'''.” A basic reference design may be found [http://warp.rice.edu/trac/browser/RefDesigns/WARP_v_1_1/Xilkernel_dynmem_ex_for_WARP_v_1_1_XPS8.zip here]. It is also implemented in the [http://warp.rice.edu/trac/wiki/ACKMAC ACKMAC Research Application]. The following are some of the common or more important functions involved in working with dynamic memory:
     59Xilkernel’s dynamic memory functions are used for allocating buffers of custom sizes and widths. The buffers are made from a preset memory table located in the “'''OS and Libraries'''” section of “'''Software Platform Settings'''.”  This functionality is useful for creating a buffer repository for memory structures of custom size – such as a packet. The dynamic memory allocation functions provide no resource-locking mechanisms, however. Dynamic memory API may be found in “'''$EDK\doc\oslib_rm.pdf'''.” A basic reference design may be found [http://warp.rice.edu/trac/attachment/wiki/xilkernel_ref/files/Xilkernel_dynmem_ex_for_WARP_v_1_1_XPS8.zip?format=raw here]. It is also implemented in the [http://warp.rice.edu/trac/wiki/ACKMAC ACKMAC Research Application]. The following are some of the common or more important functions involved in working with dynamic memory:
    6060 * '''bufcreate( )''' – upon a successful call, the function will create a buffer ID given a requested depth (number of blocks) and width (size of blocks).
    6161 * '''bufdestroy( )''' – destroys the buffer ID, but not the reserved memory pool
     
    6565== Message Queues ==
    6666
    67 Message Queues are an extremely powerful feature of xilkernel. They are a very easy and safe means of transferring data back and forth between multiple processes. Messaging is safe because the functionality uses semaphores internally. It’s easy because messages can take in custom structs. Only four functions are needed to setup, send and receive messages between threads. There is also support for having multiple messages in the system. Message Queue API may be found in “'''$EDK\doc\oslib_rm.pdf'''.” A message queue demo for WARP may be found [http://warp.rice.edu/trac/browser/RefDesigns/WARP_v_1_1/Xilkernel_msg_queue_ex_for_WARP_v_1_1_XPS8.zip here]. The following are some of the common or more important functions involved in working with message queues:
     67Message Queues are an extremely powerful feature of xilkernel. They are a very easy and safe means of transferring data back and forth between multiple processes. Messaging is safe because the functionality uses semaphores internally. It’s easy because messages can take in custom structs. Only four functions are needed to setup, send and receive messages between threads. There is also support for having multiple messages in the system. Message Queue API may be found in “'''$EDK\doc\oslib_rm.pdf'''.” A message queue demo for WARP may be found [http://warp.rice.edu/trac/attachment/wiki/xilkernel_ref/files/Xilkernel_msg_queue_ex_for_WARP_v_1_1_XPS8.zip?format=raw here]. The following are some of the common or more important functions involved in working with message queues:
    6868 * '''msgget( )''' – returns an ID number for a message queue given an unused/empty key value.
    6969 * '''msgctl( )''' – can be used to either copy the message queue’s data structure into a buffer, or destroy the message queue, given a message queue ID number.
     
    8181 1. Have a function prepared with the handler name
    8282
    83 A basic timer interrupt demo for xilkernel may be found [http://warp.rice.edu/trac/browser/RefDesigns/WARP_v_1_1/Xilkernel_timer_interrupt_ex_for_WARP_v_1_1_XPS8.zip here]. The xilkernel API documentation for xilkernel interrupts may be found in “'''$EDK\doc\oslib_rm.pdf'''.”
     83A basic timer interrupt demo for xilkernel may be found [http://warp.rice.edu/trac/attachment/wiki/xilkernel_ref/files/Xilkernel_timer_interrupt_ex_for_WARP_v_1_1_XPS8.zip?format=raw here]. The xilkernel API documentation for xilkernel interrupts may be found in “'''$EDK\doc\oslib_rm.pdf'''.”
    8484[[BR]]
    8585[wiki:ppc_prog_overview/EDK_prog PREV: EDK Programming Essentials] ||| [wiki:ppc_prog_overview HOME] ||| [wiki:ppc_prog_overview/alt_OS NEXT: Alternative Operating Systems]