Subversion Repositories shark

/*

 * Project: S.Ha.R.K.

 *

 * Coordinators:

 *   Giorgio Buttazzo    <giorgio@sssup.it>

 *   Paolo Gai           <pj@gandalf.sssup.it>

 *

 * Authors     :

 *   Paolo Gai           <pj@gandalf.sssup.it>

 *   Massimiliano Giorgi <massy@gandalf.sssup.it>

 *   Luca Abeni          <luca@gandalf.sssup.it>

 *   (see the web pages for full authors list)

 *

 * ReTiS Lab (Scuola Superiore S.Anna - Pisa - Italy)

 *

 * http://www.sssup.it

 * http://retis.sssup.it

 * http://shark.sssup.it

 */

/**

 ------------

 CVS :        $Id: srp.h,v 1.1 2005-02-25 10:40:58 pj Exp $

 File:        $File$

 Revision:    $Revision: 1.1 $

 Last update: $Date: 2005-02-25 10:40:58 $

 ------------

 This file contains the Stack Resource Policy (SRP) Protocol

 Title:

   SRP (Stack Resource Policy)

 Resource Models Accepted:

   None

 Description:

   This module implement the Stack Resource policy using the shadow field

   of the task descriptor. No difference is made upon the task model of the

   tasks that use SRP mutexes.

   A SRP mutex is created passing the SRP_mutexattr structure to mutex_init.

   In effect, this module doesn't work correctly if it is

   used, for example, with a Round Robin Module; in this case we

   can have a task B that preempts A, but when B finishes his timeslice, A

   can be scheduled by the RR module, and the SRP can't block it, because

   the SRP module can not control preemptions (it works only using the shadow

   field at lock and unlock time!!!).

   Note that this problen not affect the EDF, RM & co. algorithms... because

   if B preempts A, A will never preempts on B...

   A task that want to use the SRP protocol MUST declare it using a

   SRP_RES_MODEL in the task_create. Only the first SRP_RES_MODEL is

   considered.

   A task that want to use a SRP mutex have to declare it with the

   SRP_usemutex function as last parameter of a task_create call, AFTER

   the specification of the preemption level.

 Exceptions raised:

   XMUTEX_OWNER_KILLED

     This exception is raised when a task ends and it owns one or more

     mutexes

   XSRP_UNVALID_LOCK

     This exception is raised when a task try to lock a srp mutex but

     it don't have the provilege.

 Restrictions & special features:

   - This module is NOT Posix compliant

   - This module can manage any number of SRP mutexes.

   - If a task ends (because it reaches the end of the body or because it

     is killed by someone) and it owns some mutex, an exception is raised.

   - if a mutex unlock is called on a mutex not previously

     locked or previously locked by another task an exception is raised

   - A SRP mutex can not be statically allocated

   - The module is incompatible with the primitive TASK_JOIN, so the tasks

     that uses SRP can NOT call task_join.

**/

/*

 * Copyright (C) 2000 Paolo Gai

 *

 * This program is free software; you can redistribute it and/or modify

 * it under the terms of the GNU General Public License as published by

 * the Free Software Foundation; either version 2 of the License, or

 * (at your option) any later version.

 *

 * This program is distributed in the hope that it will be useful,

 * but WITHOUT ANY WARRANTY; without even the implied warranty of

 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

 * GNU General Public License for more details.

 *

 * You should have received a copy of the GNU General Public License

 * along with this program; if not, write to the Free Software

 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

 *

 */

#ifndef __SRP_H__

#define __SRP_H__

#include <kernel/model.h>

#include <kernel/descr.h>

#include <arch/sys/cdefs.h>

__BEGIN_DECLS

RLEVEL SRP_register_module(void);

extern __inline__ RES_MODEL *SRP_usemutex(mutex_t *m) {

  return (RES_MODEL *)m->opt;

};

__END_DECLS

#endif