ISSUE:

How are wait locks implemented in the Windows 95/Windows NT environment?

SOLUTION:

Due to the non-preemptive nature of Windows 3.x, a wait lock never relinquishes control, and can result in a deadlock situation. Therefore, when a 16-bit application is running on Windows 3.x, wait locks are "converted" by the Btrieve for Windows workstation engine to no-wait locks.

Multiple 16-bit Windows applications run in the same Virtual DOS Machine (VDM) under Windows NT (by default), and under Windows 95 always. Applications that are running in the same VDM are NOT preemptive with regards to each other.

If a 16-bit Windows application uses thunking to get to the 32-bit engine on Windows NT or Windows 95, Btrieve is aware of the fact that the request was made from the 16-bit subsystem and converts the wait lock to a no-wait lock just as if the application was running on Windows 3.x.

Native Windows 32-bit applications are all running as separate processes on Windows NT and Windows 95. They fully support the preemptive nature of the 32-bit operating systems.

A wait lock originated by a Win32 application is handled as it is, namely the application will not get control back until the lock is granted or a deadlock occurs.

This information is from the Pervasive Software Tech Tips Database.

ArticleID: BTRTT-96101103
TITLE: Wait Locks and No-Wait Locks
DATE: 11 October 1996
PRODUCT: Btrieve for Windows & Windows 95
VERSION: 6.15
KEYWORDS: Wait Lock, No-Wait Lock, Deadlock, preemptive SUPPORT