Session reference counts in v3.2 are a sum of:
Several of the UPI functions are involved in maintaining the count of permanent external references. They are listed here along with their semantics with respect to reference counts (and how these semantics have changed from x-kernel version 3.1):
xCreateSessn( ... )The newly created session has an initial reference count of 0 (it was 1 in v3.1.)
xOpen( ... )The session returned by invoking the lower protocol's open routine has its reference count incremented before it is returned to the caller of xOpen, indicating that the caller now has a permanent reference to the session. (xOpen did not manipulate reference counts in v3.1.)
xClose( XObj s )Decrements the reference count of the session, indicating that a permanent reference to the session has been released. The lower protocol's close operation is called only if the session's new reference count is zero. (xClose always invoked the lower protocol's close operation in v3.1.)
xDuplicate( XObj s )
By default, increments the session's reference count, indicating that a new permanent reference to the session has been created. If the session has its own duplicate function, that is called instead. (xDuplicate did not exist in v3.1.)
To understand the second component of the reference count, the number of outstanding xPops on a session, it is important to realize that a protocol does not have explicit references to its own sessions. That is, while a protocol usually maintains pointers to its sessions (in a map) and invokes operations on them, the sessions' reference counts do not take these pointers into account. (This is why xCreateSessn returns an object with a reference count of 0 and not 1.)
For a protocol to safely send this session pointer outside of the protocol (e.g., as a parameter in xDemux), it needs to turn the pointer into a reference by incrementing the session's reference count. It could do this by calling xDuplicate on the session as soon as it is extracted from the session map, making the external call, and then closing the session. But since all protocols must do this for incoming messages, this functionality has been absorbed into xPop. xPop increments the reference count of the session before calling the pop function and decrements it (possibly calling the session's close operation) afterwards.
It could be argued that all UPI functions, not just xPop, should indicate their use of a session by incrementing the reference count at their start and decrementing it at their completion. To perform any other UPI operation on a session, however, one must already have a reference to that session. As long as an xClose is not performed on that reference, the session is not going to go away; maintaining reference counts for these operations is not necessary. xPops are different in that a session's reference count does not reflect that its protocol may send messages up through it.
Note that reference counts will not help a protocol which performs an xClose on a session reference while another thread has an outstanding operation on that same reference. To perform such a sequence is a protocol error. If two threads share a session reference, they should either synchronize to avoid such sequences or they should duplicate the reference with xDuplicate and each thread should xClose its reference when it is through.