Sylixos one of the relationships with Linux interfaces

1. Scope of application

This document can be used as a reference for quickly porting Linux-powered source code or library source code to Sylixos.

2. Mutex Signal Volume2.1 Introduction to Concepts

The amount of mutex (also known as mutex in Linux) is because multithreading exists for critical section access. Only the line friend that owns the mutex has permission to access the resource, and the thread that is currently occupying the resource should hand over the owning mutex after the task has been processed so that other threads can access the resource after it is acquired.

The mutex semaphore can be understood as a binary semaphore with a priority ceiling and a priority inheritance mechanism (intended to solve the priority reversal problem) with an initial value of true.

Because the mutex semaphore needs to record the owner thread and adjust the priority, the interrupt service program cannot wait and release the mutex semaphore, and only the owner line of the mutex semaphore friend has the right to release the mutex semaphore.

2.2 Linux interface and Sylixos interface

The API that operates the mutex in Linux and the API corresponding to the operating mutex semaphore in Sylixos is shown in table 2-1.

Table 2-1 mutually exclusive Semaphore interface correspondence relation

Linux Medium Interface	Sylixos Medium Interface	Function description
Mutex_init	Api_semaphoremcreate	Create a mutex signal volume
Mutex_destroy	Api_semaphoremdelete	Destroy the mutex signal volume
Mutex_lock	Api_semaphorempend	Blocking the request for mutex signal volume
Mutex_trylock	Api_semaphorempend	Non-blocking request mutex signal volume
Mutex_unlock	Api_semaphorempost	Release the mutex signal amount
Mutex_is_locked	Api_semaphoremstatus	Determine the state of the mutex semaphore

3. Detailed description

3.1 Mutually exclusive semaphore structure

The mutex semaphore in Linux is represented by a struct mutex, as shown in Listing 3-1, and in Sylixos, the mutex is represented by a lw_handle-type mutex handle.

List of programs 3-1 Linux of the struct Mutex structure

struct Mutex {/* 1:unlocked, 0:locked, negative:locked, possible waiters */atomic_t count;spinlock_t wait_lock;struct l Ist_head wait_list; #if defined (config_debug_mutexes) | | Defined (CONFIG_SMP) struct task_struct *owner; #endif #ifdef config_mutex_spin_on_ownervoid *spin_mlock; #endif #ifdef Config_debug_mutexesconst Char *name;void *magic; #endif #ifdef config_debug_lock_allocstruct Lockdep_map dep_map;# ENDIF};

3.2 Creating a mutex semaphore

linux :void mutex_init  (Struct mutex *mutex); sylixos:lw_handle lw_semaphorem_create  (cpchar        pcname ,                                 UINT8          ucCeilingPriority,                                  ULONG         ulOption,                                  lw_object_id *pulid); 

• Linux:

Creating a mutually exclusive semaphore requires only defining a struct mutex variable and calling Mutex_init, and the Linux system will name the mutex itself.

After a successful creation, the defined mutex variable can be used directly when the mutex semaphore is requested and released.

• Sylixos:

You need to specify the name of the semaphore when creating the mutex semaphore, and set the options manually.

After a successful creation, the semaphore handle returned by Lw_semaphorem_create is required to request and release the mutex semaphore.

3.3 Destroying mutually exclusive semaphores

linux :void mutex_init  (Struct mutex *mutex); sylixos:lw_handle lw_semaphorem_create  (cpchar        pcname ,                                 UINT8          ucCeilingPriority,                                  ULONG         ulOption,                                  lw_object_id *pulid); 

• Linux:

Destroying a mutex semaphore is the address of the mutex variable that is passed in.

• Sylixos:

Destroying a mutex semaphore is the address of the mutex handle that is passed in.

3.4 Blocking request mutex signal volume

Linux:void mutex_lock (struct mutex *mutex); Sylixos:ulong lw_semaphorem_wait (Lw_handle ulid, ULONG ultimeout);

• Linux:

The basic logic of Mutex_lock is: if the mutex can be obtained, then directly get, jump out; otherwise enter the loop to test the state of the mutex repeatedly.

In the loop, if you can get the mutex, exit the loop, otherwise set the current process's state to be non-interruptible, unlock its own spin lock, and go to sleep. When it is scheduled to wake up, it obtains its own spin lock and enters a new cycle of querying its own state (the state of the mutex).

• Sylixos:

If you set the parameter ultimeout to Lw_option_wait_infinite, the use effect is the same as for Linux Mutex_lock.  

3.5 non-blocking request mutex signal volume

Linux:int mutex_trylock (struct mutex *mutex); Sylixos:ulong lw_semaphorem_wait (Lw_handle ulid, ULONG ultimeout);

• Linux:

The Mutex_trylock is used to attempt to obtain a mutex without waiting, and returns 1 if it is successfully fetched, otherwise returns 0 without waiting.

• Sylixos:

set Ultimeout to lw_option_not_wait, use the same effect as mutex_trylock.

3.6 Releasing the mutex signal amount

Linux:int mutex_unlock (struct mutex *mutex); Sylixos:ulong lw_semaphorem_post (Lw_handle ulid);

• Linux:

Releasing a mutex semaphore is the address of the mutex variable that is passed in.

• Sylixos:

destroying a mutually exclusive semaphore is the handle of the mutex semaphore that is passed in.

3.7 Determining the state of the mutex semaphore

linux :int mutex_is_locked  (Struct mutex *mutex); sylixos:ulong lw_semaphorem_status  (lw_handle ulid,                              BOOL      *pbValue,                              ULONG     *pulOption,                              ulong     *pulthreadblocknum);                             ULONG Lw_SemaphoreM_StatusEx  (Lw_handle  ulid,                               BOOL       *pbValue,                                ULONG     *pulOption,                                ULONG     *pulThreadBlockNum,                                lw_handle *pulownerid);

• Linux:

Mutex_is_locked can return the current state of a mutex, return 1 to indicate that the mutex has been applied, and 0 indicates that it has not been applied.

• Sylixos:

gets the current state of the mutex, which requires the use of the Lw_semaphorem_status or Lw_semaphorem_statusex interface. These two function parameter pbvalue can return the state of the current mutex semaphore.  

4. Summary

This article explains how the Linux driver source code or library source code used in the mutex, how to quickly ported to Sylixos, and did not explain in detail the different principles of the implementation of the various interfaces, the current replacement relationship is already in the porting GPU library.

Sylixos one of the relationships with Linux interfaces