@@ -15,19 +15,18 @@ When a user-mode thread releases a lock, the lock status is first checked in use
...
@@ -15,19 +15,18 @@ When a user-mode thread releases a lock, the lock status is first checked in use
When thread scheduling is required to resolve lock contention or lock release in user space, the futex system call is invoked to pass the user-mode lock address to the kernel. The user-mode locks are distinguished by lock address in the futex of the kernel. The available virtual address space in user space is 1 GiB. To facilitate search and management of lock addresses, the kernel futex uses hash buckets to store the user-mode locks.
When thread scheduling is required to resolve lock contention or lock release in user space, the futex system call is invoked to pass the user-mode lock address to the kernel. The user-mode locks are distinguished by lock address in the futex of the kernel. The available virtual address space in user space is 1 GiB. To facilitate search and management of lock addresses, the kernel futex uses hash buckets to store the user-mode locks.
There are 80 hash buckets used to store shared locks (hashed based on physical addresses). The private/shared attributes are determined by initialization of user-mode locks and the input parameters in the futex system call.
There are 80 hash buckets. Buckets 0 to 63 store private locks (hashed with the virtual address), and buckets 64 to 79 store shared locks (hashed with the physical address). The private/shared attributes are determined by initialization of user-mode locks and the input parameters in the futex system call.
## Futex Design
As shown in the following figure, each futex hash bucket stores the futex nodes with the same hash value linked in a futex_list. Each futex node corresponds to a suspended task. The key value of a node uniquely identifies a user-mode lock. The nodes with the same key value added to a queue_list indicate a queue of tasks blocked by the same lock.
**Figure 1** Futex design
**Figure 1** Futex design
![](figures/futex-design.jpg"futex-design")
![](figures/futex-design.jpg"futex-design")
As shown in the above figure, each futex hash bucket stores the futex nodes with the same hash value linked in a futex_list. Each futex node corresponds to a suspended task. The key value of a node uniquely identifies a user-mode lock. The nodes with the same key value added to a queue_list indicate a queue of tasks blocked by the same lock.
## Available APIs
## Futex Operations
APIs of the futex module
The Futex module supports the following operations.
## cl.distributeddatamgr.1 Change of int (*close)(OH_Cursor *cursor) in OH_Cursor Struct to int (\*destroy)(OH_Cursor \*cursor)
**Change Impact**
This change is incompatible with earlier versions. The function pointer name is changed from **close** to **destroy**. The input parameters and return values remain unchanged.
**Key API/Component Changes**
Before change:
```ts
int(*close)(OH_Cursor*cursor);
```
After change:
```ts
int(*destroy)(OH_Cursor*cursor);
```
**Adaptation Guide**
Example:
Code before change:
```
cursor->close(cursor);
```
Code after change:
```
cursor->destroy(cursor);
```
## cl.distributeddatamgr.2 Change of int (\*destroyPredicates)(OH_Predicates \*predicates) in OH_Predicates Struct to int (*destroy)(OH_Predicates *predicates)
**Change Impact**
This change is incompatible with earlier versions. The function pointer name is changed from **destroyPredicates** to **destroy**. The input parameters and return values remain unchanged.
## cl.distributeddatamgr.3 Change of int (\*destroyValueObject)(OH_VObject \*valueObject) in OH_VObject Struct to int (\*destroy)(OH_VObject \*valueObject)
**Change Impact**
This change is incompatible with earlier versions. The function pointer name is changed from **destroyValueObject** to **destroy**. The input parameters and return values remain unchanged.
**Key API/Component Changes**
Before change:
```ts
int(*destroyValueObject)(OH_VObject*valueObject);
```
After change:
```ts
int(*destroy)(OH_VObject*valueObject);
```
**Adaptation Guide**
Example:
Code before change:
```
valueObject->destroyValueObject(valueObject);
```
Code after change:
```
valueObject->destroy(valueObject);
```
## cl.distributeddatamgr.4 Change of int (\*destroyValuesBucket)(OH_VBucket \*bucket) in OH_VBucket Struct to int (\*destroy)(OH_VBucket \*bucket)
**Change Impact**
This change is incompatible with earlier versions. The function pointer name is changed from **destroyValuesBucket** to **destroy**. The input parameters and return values remain unchanged.
**Key API/Component Changes**
Before change:
```ts
int(*destroyValuesBucket)(OH_VBucket*bucket);
```
After change:
```ts
int(*destroy)(OH_VBucket*bucket);
```
**Adaptation Guide**
Example:
Code before change:
```
valueBucket->destroyValuesBucket(valueBucket);
```
Code after change:
```
valueBucket->destroy(valueBucket);
```
## cl.distributeddatamgr.5 Change of OH_Rdb_Config Struct Member Variables
**Change Impact**
The changes are incompatible with earlier versions. <br>The type of **securityLevel** is changed from **enum OH_Rdb_SecurityLevel** to **in**.<br>The member variable **path** is deleted.<br>The member variables **selfSize**, **dataBaseDir**, **storeName**, **bundleName**, and **moduleName** are added.
**Key API/Component Changes**
OH_Rdb_Config before change:
```ts
typedefstruct{
constchar*path;
boolisEncrypt;
enumOH_Rdb_SecurityLevelsecurityLevel;
}OH_Rdb_Config;
```
OH_Rdb_Config after change:
```ts
typedefstruct{
intselfSize;
constchar*dataBaseDir;
constchar*storeName;
constchar*bundleName;
constchar*moduleName;
boolisEncrypt;
intsecurityLevel;
}OH_Rdb_Config;
```
**Adaptation Guide**
When creating an RDB store with **OH_Rdb_Config**, you need to pass in the bundle name and module name.
## cl.distributeddatamgr.6 Change of const char *path in OH_Rdb_DeleteStore() to const OH_Rdb_Config *config
**Change Impact**
This change is incompatible with earlier versions. The input parameter is changed from **const char *path** to **const OH_Rdb_Config *config**.