Singleton class that manages the grouping of sessions for the Binlog Group Commit (BGC), using a ticketing system.
More...
Singleton class that manages the grouping of sessions for the Binlog Group Commit (BGC), using a ticketing system.
Entities
The envolved abstract entities are:
- Ticket: represented by a number, it has a processing window within which one may decide the amount of sessions one wish to have processed.
- Session: the unit for what will be processed within a ticket processing window. Usually, it represent THD sessions reaching the beginning of the binlog group commit but it's just an abstract concept.
- Front Ticket: the ticket for which the processing window is active.
- Back Ticket: the ticket that is open to assigning more sessions, it may or may not have it's processing window active.
- On-wait Tickets: tickets that aren't open to assigning more sessions and haven't, yet, had their processing window activacted.
- Session-count Queue: a queue keeping the total sessions assigned to each ticket that is closed to assignments (front + on-wait).
Operations
The overall set of available operations are:
- Request a session to be assigned to a ticket.
- Initialize a new back ticket, meaning that after such operation any subsequent requests to assign a session to a ticket will assign to the newly created ticket.
- Mark a given session or a set of sessions as processed within the front ticket window.
- Close the processing window for the front ticket and activate the processing window for the next ticket in line.
Members
The class variable members are:
- A pointer to the front ticket.
- A pointer to the back ticket.
- A counter for the amount of sessions processed within the front ticket window.
- A counter for the amount of sessions assigned to the back ticket.
- A queue that holds the amount of sessions assigned to all the tickets that are closed for assginment (front + on-wait).
There is always an active back ticket and an active front ticket. At instance initialization, both are set to 1
and, in the possibility of the underlying ticket counter variable to wrap around, the first number will still be 1
. The maximum value for a ticket is 2^63-1.
Thread-safe and serialization
All operations are thread-safe. The operations of assigning a session to the back ticket (assign_sesssion_to_ticket
) and of closing the back ticket to assignments and creating a new one (push_new_ticket
) are serialized between them. The operations of adding a session to the front ticket processed sessions count (add_processed_sessions_to_front_ticket
) and of closing the front ticket processing window (pop_front_ticket
) are serialized between them. Any other type of concurrence between operations is serialized only at the atomic variable level.
Serialization between the above described operations is necessary to keep consistent and in-sync the class member values while changing or checkings the ticket session counters and changing the ticket pointers.
Operations are serialized by using the most significant bit of each of the ticket pointer atomic variables and mark them as in use (set to 1
) or not in use (set to 0
). The first thread to be able to compare the ticket pointer atomic variable with a value that has the most significant bit unset and exchange it by a value with the most significant bit set (using a CAS) gets the ownership over the pointer operations. This mechanism allows us to atomically compare two distinct values, the ticket value in itself and whether or not it's in use by another thread.
Usage patterns
The API usage may be divided in three common patterns:
- Processing-window-wait: assign a session to a ticket, wait for the assigned ticket to get to the front and have an active processing window and add the session to the front ticket processed sessions.
- Front-ticket-closing: assign a session to a ticket, wait for the assigned ticket to get to the front, finish the front ticket processing window and notify all waiting threads that a new front ticket processing window is activated.
- Back-ticket-closing: close the back ticket to assigments and create a new back ticket.
Processing-window-wait
In this pattern, the back ticket assigned sessions counter is incremented and the back ticket is returned to the API caller. The caller should wait for the returned ticket to be the front ticket, in order to be able to add the session to the front ticket processed sessions counter. The code pattern is something along the lines:
Global shared scope std::mutex ticket_processing_window_mtx; std::condition_variable ticket_processing_window; ... auto &ticket_manager = binlog::Bgc_ticket_manager::instance(); auto this_thread_ticket = ticket_manager.assign_session_to_ticket();
while (this_thread_ticket != ticket_manager.get_front_ticket()) { std::unique_lock lock{ticket_processing_window_mtx}; ticket_processing_window.wait(lock); } ticket_manager.add_processed_sessions_to_front_ticket(1); ...
Front-ticket-closing
In this pattern, the back ticket assigned sessions counter is incremented and the back ticket is returned to the API caller. The caller should wait for the returned ticket to be the front ticket, in order to be able to add the session to the front ticket processed sessions counter. Only then, it is in a position to close the front ticket processing window, start a new front ticket processing window and notify all threads. The code pattern is something along the lines:
Global shared scope std::mutex ticket_processing_window_mtx; std::condition_variable ticket_processing_window; ... auto &ticket_manager = binlog::Bgc_ticket_manager::instance(); auto this_thread_ticket = ticket_manager.assign_session_to_ticket();
while (this_thread_ticket != ticket_manager.get_front_ticket()) { std::this_thread::yield(); } ticket_manager.add_processed_sessions_to_front_ticket(1);
while (std::get<1>(ticket_manager.pop_front_ticket()) == this_thread_ticket) { { std::unique_lock lock{ticket_processing_window_mtx}; ticket_processing_window.notify_all(); } std::this_thread::yield(); } ...
Note that there is a loop associated with pop_front_ticket
. This operation only closes the front ticket processing window if the counter for the front ticket assigned sessions equals the counter for the front ticket processed sessions. Since the function returns an std::pair
with the front ticket values before and after the operation, one may need to check if the values are different.
When pop_front_ticket
returns different before and after values, it means that the front ticket pointer now points to the after value and that the assigned sessions count for the before value was poped from the session-count queue.
Back-ticket-closing
In this pattern, the back ticket assigned sessions count is pushed into the session-count queue, set to 0
and the back ticket pointer is set to the next value. The code pattern is something along the lines:
auto [before_ticket, after_ticket] = ticket_manager.push_new_ticket();
If there is the need to assign a session to the finishing back ticket before it's finished and do it atomically with the finish operation, the following code pattern is also supported:
auto [before_ticket, after_ticket] = ticket_manager.push_new_ticket( binlog::BgcTmOptions::inc_session_count);
The above means that a session was assigned to the before_ticket
(added to assigned sessions counter) before such value was pushed to the session-count queue.
- See also
- unittest/gunit/bgc_ticket_manager-t.cc