|
This operation associates a thread with a server, which means that it starts consuming the server's budget and is executed according to the contract established for that server. If the thread is already bound to another server, and error is returned. It fails if the server's policy is different than FSF_NONE, or if there is already a thread bound to this server Implementation dependent issue: In order to allow the usage of application defined schedulers, the given thread must not have the scheduling policy SCHED_APP and at the same time be attached to an application scheduler different than the fsf scheduler.
|
|
The operation eliminates the specified server and recalculates all necessary parameters for the contracts remaining in the system. This is a potentially blocking operation; it returns when the system has made the changes effective.
|
|
This operation stores the contract parameters currently associated with the specified server in the variable pointed to by contract. It returns an error if the server id is incorrect.
|
|
The operation reports on the status of the last renegotiation operation enqueued for the specified server. It is callable even after notification of the completion of such operation, if requested.
|
|
This operation stores the Id of the server associated with the specified thread in the variable pointed to by server. It returns an error if the thread does not exist, it is not under the control of the scheduling framework, or is not bound.
|
|
The operation negotiates a contract for a new server. If the on-line admission test is enabled it determines whether the contract can be admitted or not based on the current contracts established in the system. Then it creates the server and recalculates all necessary parameters for the contracts already present in the system. This is a potentially blocking operation; it returns when the system has either rejected the contract, or admitted it and made it effective. It returns zero and places the server identification number in the location pointed to by the server input parameter if accepted, or an error if rejected. No thread is bound to the newly created server, which will be idle until a thread is bound to it. This operation can only be executed by threads that are already bound to an active server and therefore are being scheduled by the fsf scheduler.
|
|
This operation negotiates a contract for a new server, and binds the calling thread to it. If the contract is accepted it returns zero and copies the server identification number in the location pointed to by the server input parameter. If it is rejected, an error is returned. The server is created with the FSF_NONE scheduling policy, which means no hierarchical scheduling, and only one thread per server, except for the case of background tasks. Implementation dependent issue: In order to allow the usage of application defined schedulers, the calling thread must not have the SCHED_APP scheduling policy and at the same time be attached to an application scheduler different than the fsf scheduler; in such case, an error is returned. After a successful call the calling thread will have the SCHED_APP scheduling policy and will be attached to the fsf scheduler.
|
|
This operation negotiates a contract for a new server, creates a thread and binds it to the server. If the contract is accepted, the operation creates a thread with the arguments thread, attr, thread_code and arg as they are defined for the pthread_create() POSIX function call, and attaches it to the fsf scheduler. Then, it binds the created thread to the new server. It returns zero and puts the server identification number in the location pointed to by the server input parameter. The attr parameter is overwritten as necessary to introduce the adequate scheduling attributes, according to the information given in the contract. The server is created with the FSF_NONE scheduling policy, which means no hierarchical scheduling, and only one thread per server, except for the case of background tasks. If the contract is rejected, the thread is not created and the corresponding error is returned.
|
|
This operation analizes the schedulability of the context that results from negitiating the contracts specified in the contracts_up list and cacelling the contracts referenced by the servers_down list. If the overall negotiation is successful, a new server will be created for each of the elements of the contracts_up group, the servers in servers_down will be cancelled, the list of new server ids will be returned in the variable pointed to by servers_up, and the variable pointed to by accepted will be made true. Otherwise, this variable will be made false, and no other effect will take place. The function returns the corresponding error code if any of the contracts is not correct or any of the server is is not valid.
|
|
The operation renegotiates a contract for an existing server. If the on-line admission test is enabled it determines whether the contract can be admitted or not based on the current contracts established in the system. If it cannot be admitted, the old contract remains in effect and an error is returned. If it can be admitted, it recalculates all necessary parameters for the contracts already present in the system anr returns zero. This is a potentially blocking operation; it returns when the system has either rejected the new contract, or admitted it and made it effective.
|
|
The operation enqueues a renegotiate operation for an existing server, and returns immediately. The renegotiate operation is performed asynchronously and the calling thread may continue executing normally. Of course, wheter the operation is performed immediately or not depends on the relative priority of the service thread and the calling thread, on the scheduler used, etc. When the renegotiation is completed, if the on-line admission test is enabled it determines whether the contract can be admitted or not based on the current contracts established in the system. If it cannot be admitted, the old contract remains in effect. If it can be admitted, it recalculates all necessary parameters for the contracts already present in the system. When the operation is completed, notification is made to the caller, if requested, via a signal. The status of the operation (in progress, admitted, rejected) can be checked with the get_renegotiation_status operation. The argument sig_notify can be NULL_SIGNAL (no notification), or any POSIX signal; and in this case sig_value is to be sent with the signal.
|
|
This operation unbinds a thread from a server. Since threads with no server associated are not allow to execute, they remain in a dormant state until they are either eliminated or bound again. If the thread is inside a critical section the effects of this call are deferred until the critical section is ended Implementation dependent issue: in the implementation with an application scheduler, the thread is still attached to the fsf scheduler, but suspended.
|