Thread safe registries and families

[jupp0r]

Currently, instances of registries and families must only be accessed by a single thread. This would force users of this library to implement locking the objects externally, which is quite inconvenient. It would be nice to add locks internally.

[penberg]

I actually tend to disagree. The problem with library internal locks is that there's no way for application developers to by-pass them. This makes the single-threaded case pay for locking overhead for no gain.

I don't think there's anything wrong with requiring applications to provide their own locking. However, if you really, really want to provide a thread-safe API, you should introduce two versions of the API, similar to what C++ is doing with relaxing locking in std::shared_ptr and introducing a std::experimental::atomic_shared_ptr.

[jupp0r]

Thanks for your insights, I generally agree. My rationale is that it would probably be a rare event to modify the set of metrics that are exposed, so the costs of locking would not be significant. This is also the approach that Java and Go prometheus client libraries take.

An additional optimization step (leveraging the full power of C++), that I would much more like to implement is that metrics and labels dimensions are created at compile time and lookups become zero cost.

[penberg]

@jupp0r I'm not sure I understand your thinking here. If you make registration thread-safe with locking, surely you also need to take the same locks while reading the counters (which is a common operation)?

[jupp0r]

@penberg reading would only be done once per scrape which happens once every 10s to several minutes so. During the scrape, access to the list of metrics in a registry would have to be locked. The metric values themselves are atomic (already) and can be read and written from different threads without races. Does that make sense?

[penberg]

@jupp0r If you don't take the lock while you access the metric, what prevents the application from removing a metric (and freeing it) from the registry while another thread is accessing it?

[jupp0r]

@penberg that's entirely possible. The other thread would be able to change its value, but it would not be part of the next scrape.

edit: for this to work, metrics would have to be stored as shared_ptrs, though, which I don't particularly like.