BASIS will soon release Visual PRO/5® revision 4.0, which has several optimizations and enhancements to improve speed and performance in a multi-user environment. These include very specific optimizations, such as radically reducing the amount of time necessary to open files and broader enhancements, such as new locking capabilities.

Faster File Opens
After profiling several Visual PRO/5 applications, it became apparent that one of the areas impacting performance was file opens. While file opens in a single-user environment didn't adversely affect the application, it became challenging as more and more users attempted to access the same file. Surprisingly, this occurred even if the users were accessing the same file at different times. It's reasonable to expect the file opens to take longer in a state of contention, where several processes are vying for exclusive access to the file. However, the file opens became slower - even when only one process was attempting to open the file - but only if several other processes already had the file open. Closer examination revealed that the "floating lock byte" method was responsible for the delays.

To resolve the problem, Visual PRO/5 now uses an advisory lock for the lock byte on Windows NT/2000/XP. This type of lock is supported natively by Windows NT-based operating systems and is significantly faster. While advisory locks are not supported on Windows 98/Me, Visual PRO/5 has taken advantage of other optimizations to improve performance on those operating systems. These optimizations are available automatically - to take advantage of the new speed, there's no need to set a SETOPTS bit or change existing code in any way.

This graph shows how Visual PRO/5 revision 4.0 opens files significantly faster than Visual PRO/5 3.12. The test was conducted with a varying number of clients simultaneously opening and closing the same file on both a mapped drive and in a Microsoft Terminal Services environment. In addition to Visual PRO/5 4.0 being able to open files substantially faster, it's much more scalable since the number of file opens per second isn't as heavily impacted by the number of users that have the file open.

Read-Only Header Locks
Along with speeding up file opens in multi-user environments, Visual PRO/5 now offers read-only header locks in the Windows NT/2000/XP environment, another important multi-user feature that only had been available under UNIX until now. This means that a Visual PRO/5 process can use a read-only lock on the header of a file before a read operation, which is significant because it doesn't require exclusive access to the header and won't block other read-only locks. What this translates to, in practice, is that you can now have several Visual PRO/5 processes simultaneously accessing the key information in the header of a file. In our tests, this had a profound impact on the amount of records Visual PRO/5 could read from files in a mapped drive environment.

Previous versions of Visual PRO/5 would lock the header of the file in such a manner to block all other access to the header by any other process. This means that if several processes all attempted to read data from a file, their access to the file header (which is a prerequisite for data access) was given in a serial fashion. One process would have exclusive access to the header, then it would relinquish control and let the next process have exclusive access. This is similar to all of the Visual PRO/5 processes standing in the same line in the supermarket checkout line. With read-only header locks, several checkout lines open up so each Visual PRO/5 process is first in line. This enhancement has the potential to play an even greater role in improving performance on machines with multiple processors (depending on the operating system's SMP implementation) as it caters to their strengths in the multi-user arena. After turning on read-only header locks via the SETOPTS vector (byte 3, bit $20$), Visual PRO/5 will still have to use blocking locks on some occasions. One such example is during a WRITE operation that results in a modification of the header. In this case, Visual PRO/5 will be changing the information in the header of the file. Consequently, it's critical that Visual PRO/5 prevents other processes from being able to read the header until it's finished with the operation. By doing this, Visual PRO/5 can ensure the integrity of the data file.

Advisory Locks
Another major improvement to Visual PRO/5 is the addition of true advisory locking in the Windows NT/2000/XP environment. Several revisions ago, BASIS introduced a quasi-advisory locking scheme to Visual PRO/5 and the NT Data Server called shadow locks. Shadow locks were turned on by virtue of the existence of the "ADVISORY_LOCKS" keyword in the config.bbx file. Shadow locks allowed Visual PRO/5 users to enjoy the benefits of advisory locks, which were only available on UNIX and NetWare platforms. However, they did have one drawback - all processes that were accessing a file had to have the same setting (shadow locks either on for all sessions or off for all sessions). If this rule were not followed in every case, it would potentially compromise the integrity of the file. In this scenario, two different processes could write to the file at the same time using incompatible locking schemes that wouldn't honor the other's locks.

This graph shows the increase in performance due to using advisory locks. The test program consisted of a varying number of remote clients simultaneously iterating through a large MKEYED file that was located on a mapped drive. Those clients running Visual PRO/5 revision 4.00 read through the file at more than twice the speed of those using Visual PRO/5 3.12.

Revision 4.0 solves this problem by introducing true advisory locking in the Windows NT/2000/XP environment - similar to what's been available on UNIX and Netware for several years. Now that this locking scheme is available, it's no longer necessary to use the "ADVISORY_LOCKS" keyword in the config.bbx file. Instead, SETOPTS byte 3, bit $40$ is used to turn this feature on or off. In addition to making this easier to implement, it is also safer, as you can turn the feature on or off in the application instead of depending on a particular keyword in a specific configuration file. Revision 4.0 still supports the "ADVISORY_LOCKS" keyword for compatibility with Windows 98/Me.

Everything presented here points to one thing: Visual PRO/5 4.0 increases your application's performance without having to modify code. While this will enable your existing applications to be more competitive in the marketplace, the key value is the increased satisfaction you and your Customers will experience with Visual PRO/5 4.0.

More information on advisory locks is available online in the BASIS product documentation.