Re:

> tracking it down, you come up with a deadlock between the
> semcl_pm_pcl semaphore and semcl_gufd semaphore.

>                    $57a (PEUTIL.PUB.SYS)  #S1573
...
>                   NM  7) SP=418526f0 RP=a.005c88d0 ?sm_close+$8
...
>                   NM  c) SP=418523f0 RP=a.00add8d4 pe_allow_not+$13c

and
>                    $6c4 (the 3rd party software shall remain nameless, lest I be sued.)  #J1448
>                   NM  3) SP=4185c490 RP=a.001945fc sem_block+$178
>                   NM  4) SP=4185c3d0 RP=a.0016cebc aligned_joint_lock_path+$34
>                   NM  5) SP=4185c2d0 RP=a.002774ec get_pcl+$8c
>                   NM  6) SP=4185c288 RP=a.00530e38 +$64
>                   NM  7) SP=4185c1c8 RP=a.00568fe4 vsm_clean_up_file_user+$1a8
>                   NM  8) SP=4185c0c8 RP=a.005c8568 sm_close_fd+$14f4
...                     ... (called from FCLOSE)

The problem is either a bug in the pe_allow / pe_disallow internals (most
probable), or in delete_protectid_entry.

The former:

   pe_allow is calling get_pcl, and then doing something (e.g., sm_close) which
   requires a less important lock.  Unfortunately, that's the opposite order
   that is happening in the other process.

   Workaround:
      in pe_allow / etc., do:

          free_pcl;
          sm_close;
          get_pcl;
          and verify that the next pin you're interested in is still alive.

      (I.e., releasing PCL will incur a programming cost)

The latter:

   Investigate why delete_protectid_entry is calling get_pcl.

      1) should there be a lock (semaphore) on the protectid entry list,
         instead of relying on PCL?

      2) can the protectedid be copied from the GUFD, the gufd
changed/close/whatever,
         then unlocked, prior to calling get_pcl?

   Does the lab have a documented semaphore hierarchy (remember SIR ranks?)?
   If yes, then is it legal to lock a GUFD semaphore and then PCL?
   (If not, then the opposite order must be legal.)
   If not legal, then delete_protectid_entry is definitely the culprit.
   If legal, then pe_allow/pe_disallow is definitely the culprit.
   If there is no documented hierarchy, then certain people who should
   have developed & published the ranking are the culprits :)

   documented
Stan Sieler                                           [log in to unmask]
www.allegro.com/sieler/wanted/index.html          www.allegro.com/sieler