[Unbound-users] Thread safety and atomicity assumptions for unbound-control set_option

[Jake Montgomery]

I'm a developer, and I sometimes make custom modifications to the the 
unbound code. I am a bit confused about the assumptions being made in 
the unbound code with regard to what is safe on multiprocessor systems.

The 'new' "unbound-control set_option" command seems to allow the 
modification of many configuration variables by directly writing to the 
globally shared config_file structure. Most of these variables are never 
used after initialization (which begs the question - why make them 
settable?) However, some of them are accessed directly during normal 
operation. AFAICT, it is possible for these variables to be written and 
read simultaneously on multiprocessor systems. The variable 
config_file->log_queries is one of many examples. I have not done an 
exhaustive search, but the examples I have found are all single integer 
values. Nonetheless, concurrent writing and reading goes against what I 
understand to be _conservative_ best practices for cross platform code.  
In addition, the variables are not marked as volatile, so it would be 
theoretically possible for subsequent reads to be optimized out by the c 
compiler, resulting in the settings changes not being reflected in 
behavioral changes on worker threads, other than the one which processed 
the command. (Admittedly, this is possible in theory, but unlikely in 
the extreme in practice, given current compilers and the scope of the 
variables.)

* This is not intended as a troll or criticism, and I have the utmost 
respect for the creators and maintainers of the unbound code base. *

It would be helpful for me to understand what assumptions and guidelines 
the unbound code uses for unprotected concurrent memory access. Armed 
with this information, I could make my modifications in a manner 
consistent with the current code.

Thanks much,
      Jake Montgomery