hcq/MaxScale
hcq/MaxScale
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Loosen the atomicity requirement for the passive parameter

Browse Source 
As the passive parameter is only used by the failover and the failover can
only be initiated by the monitor, there is no true need to synchronize the
reads and write of this parameter.

As all runtime changes are protected by the runtime lock, only partial
reads are of concern. For the supported platforms, this is not a practical
problem and it only confuses the reader when other variables are modified
without atomic operations.
This commit is contained in:
Markus Mäkelä 2017-10-27 14:40:27 +03:00
parent 600509be4a
commit 551bb81929
2 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
server/core/config_runtime.cc
View File

@ -763,10 +763,10 @@ bool runtime_alter_maxscale(const char* name, const char* value)
if (cnf.passive && !boolval)
{
// This MaxScale is being promoted to the active instance
atomic_store_int64(&cnf.promoted_at, hkheartbeat);
cnf.promoted_at = hkheartbeat;
}
atomic_store_int32(&cnf.passive, boolval);
cnf.passive = boolval;
rval = true;
}
else

2
server/core/monitor.cc
View File

@ -1758,7 +1758,7 @@ void mon_process_state_changes(MXS_MONITOR *monitor, const char *script, uint64_
mxs_monitor_event_t event = mon_get_event_type(ptr);
ptr->server->last_event = event;
ptr->server->triggered_at = hkheartbeat;
ptr->server->active_event = !atomic_load_int32(&config_get_global_options()->passive);
ptr->server->active_event = !config_get_global_options()->passive;
ptr->new_event = true;
mon_log_state_change(ptr);