[progress Communities] [progress Openedge Abl] Forum Post: Re: What Are Very Large Latch Ids?

  • Thread starter Thread starter Richard Banville
  • Start date Start date
Status
Not open for further replies.
R

Richard Banville

Guest
I gave a talk on latches at the various conferences some years back. However, since then something have changed which can make this stuff a bit more confusing than it really is. > BTW, does anybody know how Progress calls these (sub-)latches of the governing latches (BUF and LKT)? Do you mean what we call them or how we call them? They are called object latches for BUF (true object latches type 2) and Latch families for LKT (one latch governs multiple objects but not all of them). We implemented them by embedding the actual latch value/structure within the structure that requires protection. In other words, for the BUF latches, each -B buffer control structure (bktbl_t) has a latch embedded in it that is used for its own protection. BUF: latObjLatchLock2()/latObjLatchFree2(). LKT: latlatch()/latunlatch() or latObjLatchLock()/latObjLatchFree() depending on the circumstance (if the operation requires operating on multiple chains or a single chain) However, realize that the exact function names used in supporting this mechanism are subject to change without notice. > But they do not seem to be the same as the Object Number Latches introduced in 11.6: There is no such thing as "Object Number Latches". The terminology was inappropriately coined in that poorly formed message. Although these latches have not been given an appropriate name as a group, they should be thought of as "administrative latches". I will work on "socializing" that. BTW, this message is no longer used in 11.7. > Progress seems to use the pmObjectLockLock call to lock the multiplexed latches of the LKT latches (called "LHT" in _Latch VST) - Lock Table Hash Chain latches (introduced in 10.0A). This is not true. latObjLatchLock() or latlatch() is used but again, it is the mechanism that is more important than the function name (but I appreciate that you often use the function name to decipher stack traces). pmObjectLockLock() is only used to protect the plugin manager stuff, currently only implemented for replication. > 10.2B06 Service Pack Readme seems to call them the private latches: Process "Private latches" were originally introduced to protect data structures between threads of the same process, not to protect shared memory data structures. However, the same process private latch mechanism was leveraged to protect certain shared data structures. Although the mechanism was architected flexible enough to work in this way, it was incorrect to refer to this use of the latching mechanism as "private latches". The use of the term "private latches" is therefore inappropriate here. I stressed that at the time but the developer continued to call them by that name and incorrectly added references to that mechanism in messages and KBases. I should have "strong armed" it at the time but did not. It is something that Progress needs to clarify and clean up. > Do the new messages introduced in V11 talk about the same private latches? > 11.0: SYSTEM ERROR: User died holding the latch. (15767) > Desc: The user has died while holding a private latch. This message is obsolete and is no longer used anywhere as far as I can see. > 11.6: User died holding the . (18386) > Desc: User with usernum died holding a private latch as specified. Yes, this is the same, but please let's start referring to them as administrative latches. I will do what I can to clean this up throughout the organization.

Continue reading...
 
Status
Not open for further replies.
Back
Top