Hello, I have just committed a rather important change to how the Storage daemon does locking during despooling. Previously, it held an exclusive lock on the device it was despooling to, which had the effect of locking out any other thread or job that wanted to access the device, for example for scheduling.
The new mechanism simply puts a block on the device, which means that other threads can access the device structure once it is locked, but they will block if they attempt to write to the device or otherwise manipulate it. This should allow for a lot more concurrency -- however, there is a lot more locking and unlocking going on because during the write process the despooling thread must constantly lock and unlock the device when it wants to modify the device structure. The current code passes all the regression tests, but always when making such an important change in the locking/blocking mechanism, there are *lots* of possibility for race conditions (deadlocks or two threads changing something at the same time). So, I would appreciate it if all the regression testers would run their scripts and report back the results. Thanks. The current SVN revision is 5114. Best regards, Kern PS: there are still opportunities for improving the concurrency -- for example, I believe that I can completely remove the reservation lock which allows only one thread to find a drive at a time, but I will probably leave that for a later version. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
