Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Semaphore now able to be interrupted #380

Merged
merged 4 commits into from
Feb 29, 2024
Merged

Semaphore now able to be interrupted #380

merged 4 commits into from
Feb 29, 2024

Conversation

Coldwings
Copy link
Collaborator

This pull request improves the synchronization components based on waitq by adding support for interruption using thread_interrupt. The semaphore component, which was previously unable to be interrupted, is now included in this enhancement.

Interruption of a running photon thread can be beneficial in specific situations, such as during the graceful shutdown of a process. This update enables more efficient and controlled termination of threads, resulting in improved system reliability and performance.

Additionally, the internal photon thread interruption errno used by waitq has been changed to -1 by default. As a result, users can now utilize all generic error numbers to interrupt synchronization components.

thread/thread.h Outdated
@@ -362,10 +362,30 @@ namespace photon
{
return waitq::wait(timeout);
}
template<typename LOCK, typename PRED>
int wait_pred(LOCK& lock, PRED&& pred, Timeout timeout = {}) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

simply name it as wait?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change to wait by using SFINAE

thread/thread.h Outdated
return do_wait_pred([&]{ return wait(lock, timeout); }, std::forward<PRED>(pred), timeout);
}
template<typename PRED>
int wait_pred_no_lock(PRED&& pred, Timeout timeout = {}) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

simply name it as wait_no_lock?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change to wait_no_lock by using SFINAE

}
errno = err;
return ret;
}
};

class semaphore : protected waitq
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

add a wait_uninterruptible()?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

thread* resume_one(int error_number = ECANCELED);
void resume(thread* th, int error_number = -1); // `th` must be waiting in this waitq!
int resume_all(int error_number = -1);
thread* resume_one(int error_number = -1);
waitq() = default;
Copy link
Collaborator

@beef9999 beef9999 Feb 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it comes from the inside of the synchronization primitives due to technical reasons, we use -1 to distinguish from user generated ordinary error numbers (>0). And 0 has already been used for another scenario.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the default behavior of the default value -1 ? Documents should be adjusted in:

https://github.com/alibaba/PhotonLibOS/blob/main/doc/docs/api/thread.md#thread_interrupt

https://github.com/alibaba/PhotonLibOS/blob/main/doc/i18n/cn/docusaurus-plugin-content-docs/current/api/thread.md#thread_interrupt

Those documents are about photon::thread_interrupt. The default errno in photon::thread_interrupt is not changed, so it still EINTR, nothing has changed in document.

Here is all about method waitq::resume, which is protected method, not a part of API.

thread/thread.h Outdated
@@ -362,17 +362,52 @@ namespace photon
{
return waitq::wait(timeout);
}
template <typename LOCK, typename PRED,
typename = typename std::enable_if<std::is_same<
decltype(std::declval<PRED>()()), bool>::value>::type>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as long as PRED is not typed as Timeout

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and enable_if_t is shorter

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if do not limit PRED return value type, even enable_if part is meaningless.

Once PRED is callable (means PRED()() has a type) is good enough.

thread/thread.h Outdated
}
errno = err;
return ret;
}
};

class semaphore : protected waitq
{
public:
explicit semaphore(uint64_t count = 0) : m_count(count) { }
int wait(uint64_t count, Timeout timeout = {});
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any invocations of wait() that should be changed to invocations of wait_uninterruptible()?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make wait uninterruptible, keeps it works like it used to be, and add a new method wait_interruptible to present a wait that able to be interrupt might be better.

@lihuiba lihuiba merged commit cdb2600 into alibaba:main Feb 29, 2024
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants