Optimizations to improve the performance of Ramfs

[liqinggd]

Refer to #791

@StevenJiang1110 Please review this commit, thanks.

[lrh2000]

I think that you mean Ordering::Release, although I'm not sure whether or not this memory order is necessary for the thread status.

[liqinggd]

The success describes the required ordering for the read-modify-write operation that takes place if the comparison with current succeeds.

I think AcqRel is correct, it has the effects of both Acquire and Release together: For loads it uses Acquire ordering. For stores it uses the Release ordering.

[lrh2000]

Yes, but you are writing Order::Relaxed. So you should write Order::Release instead. I mean, there is a typo.

[lrh2000]

Sorry, I misunderstood your comment, so it seems we should write success = Ordering::AcqRel, failure = Ordering::Relaxed/Acquire (the failure order depends on whether we want to synchronize with the last status write if the exchange fails).

[lrh2000]

• SigQueue::dequeue (that serves a sink) works exactly the opposite way of WaitQueue::wake_one (that serves a source). In the case of SigQueue, the count's acquire-release semantics is correct but redundant as it is already guaranteed by the internal lock, so accessing count should be fine even with Ordering::Relaxed.

Well, I thought it would be another great example to discuss together in #831. So leaving this as a TODO for #831 is fine.

[liqinggd]

• SigQueue::dequeue (that serves a sink) works exactly the opposite way of WaitQueue::wake_one (that serves a source). In the case of SigQueue, the count's acquire-release semantics is correct but redundant as it is already guaranteed by the internal lock, so accessing count should be fine even with Ordering::Relaxed.

Yes, you are correct, the count will be fine with Ordering::Relaxed.

[tatetian]

To simplify thread/mod.rs, I think a new type named AtomicThreadStatus should be provided by thread/status.rs and used by thread/mod.rs. Most changes made to thread/mod.rs can be extracted to and hidden inside AtomicThreadStatus. This makes the code easier to understand and maintain.

pub struct AtomicThreadStatus(AtomicU8);

impl AtomicThreadStatus {
    pub fn load(&self, ordering: Ordering) -> ThreadStatus { ... }

    pub fn store(&self, new_status: ThreadStatus, ordering: Ordering) -> ThreadStatus { ... }

    pub fn compare_exchange( &self, current: ThreadStatus, new: ThreadStatus, success: Ordering, failure: Ordering ) -> Result<ThreadStatus, ThreadStatus>
}

The methods of AtomicThreadStatus mirrors that of AtomicU8. They take Ordering as input so that the user can decide the ordering.

[tatetian]

LGTM. Thanks for the contribution!