PSS — PSS FTF issue: PSS & Thread-Safety

The Persistent State Service draft specification does not say anything
about thread-safety. For portability, it is necessary to define the
guarantees provided by a thread-safe PSS implementation.

Proposal
--------
A catalog (session or session pool) can be either thread-safe or
thread-unsafe. A compliant implementation does not need to provide
thread-safe catalogs.
All objects provided directly or indirectly by a thread-unsafe
catalog are thread-unsafe – the application must serialize access
to any of these objects, typically by using a single thread.

(1) A storage object incarnation provided by a thread-safe catalog
is like a struct: concurrent reads are safe and do not require any
locking by the application; concurrent writes (or a concurrent
read and a concurrent write) are not thread-safe – the application
must ensure mutual exclusion to avoid problems.
Flushing a storage object is like reading this object. 'Refreshing'
a storage object is like updating it.

(2) Further, the following Session operations are not thread safe:
they are not supposed to be called concurrently, and no thread
should be using the target session (or anything in the target
session, such as an incarnation or a storage home) when they are
called:

Session::free_all
Session::refresh
Session::close
TransactionalSession::start
TransactionalSession::suspend
TransactionalSession::end

OTS operations are however safe; for example one thread can call
tx_current->rollback() while another thread calls start, suspend or
end on a session involved in this transaction, or while a thread
is using storage objects managed by that session.

accepted