- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: DCE and LIB$WAIT
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-14-2008 06:02 AM
тАО11-14-2008 06:02 AM
The program uses
V_STATUS := LIB$SPAWN ('WAIT 00:00:37');
where I would have used
V_STATUS := LIB$WAIT (37.0, 1);
There must have been a reason for this, and according the memory of one of my collegues, LIB$WAIT and DCE-code interfered causing a number of problems, and the SPWAN solution seemed the only way to solve them. But he didn't remember what was happening - it had to do messing with event flags, perhaps.
Can anyone tell us more on this issue?
Alas, I cannot tell anything on what DCE routines are actually called - we use a library enveloping (and thus hiding) the details. But if needed, I could dive into the objects to find out.
Environment:
OpenVMS 7.1 and 7.2 (Code developed and compiled on 7.2, linked and run on 7.1)
DEC VAXVMS VAX_DCEECO_015_1 V1.0
DEC VAXVMS DCE V1.5
OpenVMS Developer & System Manager
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-14-2008 07:07 AM
тАО11-14-2008 07:07 AM
Re: DCE and LIB$WAIT
Use $SETIMR & $WAITFR with a local event flag.
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-14-2008 07:43 AM
тАО11-14-2008 07:43 AM
Re: DCE and LIB$WAIT
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-14-2008 07:58 AM
тАО11-14-2008 07:58 AM
Re: DCE and LIB$WAIT
The second parameter in LIB$WAIT would prevent that, according the documentation.
What my collegue did remember is that returning to activity could explode to minutes, even if the timer expired - sometimes, indeed. (He didn't know of this flag).
We could try, though, using SETIMR and WAITEF.
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-16-2008 12:46 PM
тАО11-16-2008 12:46 PM
SolutionThere are a few potential issues with the $HIBER/$WAKE mechanism when used for synchronization. Note these aren't "bugs" as such. They're consequences of the intended design features of the mechanism which can cause application misbehaviour if code makes invalid assumptions about what other threads of execution are doing.
The first is if there is a pending $WAKE, then subsequent $WAKEs are lost. This can result in a $HIBER hanging because another thread consumed the $WAKE intended for it. The converse is a $WAKE isn't "targeted", so a $HIBER may be woken prematurely by a $WAKE for another thread.
So, in your case a call to LIB$WAIT may complete early if a $WAKE is triggered from DCE (or any other thread of execution), or, if there was already a $WAKE pending, the LIB$WAIT will consume it, potentially leaving a DCE thread hanging later on.
Properly written code should at least be immune from unexpected $WAKEs, and it should not consume $WAKEs from other threads. Protecting it from having its own $WAKEs consumed elsewhere is more difficult.
On solution is to make sure every $HIBER/$WAKE pair has a flag to check that the event you're waiting for has really happened. Here's a wait sequence with several mechanisms to eliminate spurious wakeups and spurious hangs (in this case there is some redundancy)
$HIBER side
TimeToWake=0
$WAKE ; force wakeup
$HIBER ; consume any pending wakes
WHILE NOT TimeToWake
$HIBER
ENDWHILE
$WAKE ; leave a pending wake in case we've consumed one intended for another thread
$WAKE side
TimeToWake=1
$WAKE
Of course, this assumes that any other threads are protected by a TimeToWake flag, otherwise there will be spurious wakeups.
The SPAWN ensures that the WAIT command is isolated from other $WAKEs floating around the current process. It's a relatively expensive operation since it involves process creation, but if you're waiting 37 seconds it's obviously not in a tight loop and unlikely to be a problem unless you're seriously short of process slots. Crude but effective. Unless you're desperate to conserve CPU and memory I'd recommend leaving it as is.
The other advantage of SPAWN is you're specifying the time as a string, which makes it floating point format independent. That means it will behave correctly on both Alpha and IA64 without modification. As written, the call to LIB$WAIT will fail on IA64 unless you explicitly compile with /FLOAT=F_FLOAT, or add a float-type argument.
As Hoff has mentioned recently, if the problem is hanging in $HIBER, you can use the very blunt instrument of a $SCHDWK to inject regular wakeups to compensate for some thread consuming another threads $WAKEs. This can even be done externally if the program is run in a detached process (see RUN/INTERVAL)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО11-17-2008 03:35 AM
тАО11-17-2008 03:35 AM
Re: DCE and LIB$WAIT
OpenVMS Developer & System Manager