Benoit Minisini schrieb: > On mardi 07 octobre 2008, nando wrote: >> There is a problem with your method. >> Between the execution of the KILL and the CREATION of the file, >> multitasking happens and another task could create the file just before >> the original thread executed the CREATE. >> >> In different words, if the first thread lost the CPU just after the KILL >> command due to multitasking and a second thread began the WHILE condition, >> the WHILE would not execute because the WHILE condition fails and >> then the file is CREATED with the user of the second thread. >> Then, multitasking happens and the second thread loses the CPU and the >> first thread continues and it will then create the file destroying the >> second threads information. Anything could happen in a multitasking >> environment. >> >> I use directories because folder creation is a one-step process there isn't >> time between the two steps for >> another task to steal the lock in betweem code statements. >> An example is something like... >> >> 'create lock, this can be in a SUB with tje folder name passed in >> >> counter=100 '100 loops of 0.1 sec = 10 seconds max to try lock >> flag = FALSE >> WHILE flag = FALSE >> TRY MKDIR "lock-folder-name" >> IF ERROR THEN 'it failed >> flag=TRUE >> error.clear >> WAIT 0.1 >> dec counter >> if counter<=0 then >> 'you could say the the lock took too long >> 'you could allow a user choice to retry or blindly continue. >> break 'we will assume something is locked too long >> endif >> else >> flag=FALSE >> endif >> wend >> >> >> 'unlock, this can be a SUB too >> TRY RMDKR "lock-folder-name" >> error.clear >> >> You don't need to know who has the lock because only a successful lock >> leads to code writing some important information for the thread that >> successfully locked. The unlock must follow very shortly thereafter to >> release the lock and cannot hog the lock. >> >> -Fernando >> > > Or better method: use the LOCK / UNLOCK instruction! >
Yes Benoit, we know, but this is hobby :-) just having fun with an own algorithm... But I've got a question about LOCK. I didn't know it existed. A long time ago when I started with Linux, I learned that Linux doesn't have a file locking mechanism. Isn't that true anymore? Never heard or read about it in all these years. After all, a lot of programs still use lock files, and for instance there is a discussion about Firefox 3 not running correctly on terminal servers because it's got a new file locking method which blocks more than 1 users. Having a first glance at the description of LOCK, there is one thing which leaves at least a small pain in the neck: You have to open the stream before being able to try a lock. That leaves the impression that without checking the lock, you can read/write the file anyway. Two questions: Is this LOCK just a flag? (Which I can obey or not just like I feel) Or does it really prevent any other access (or at least writing into the file)? And what happens if my program "forgets" Unlocking it? Will the file stay locked (file system wide - until reboot) or will the Lock end automagically when I close the file or when the process ends that opened the stream? (Maybe it would be nice to insert such information into the help, too) Regards Rolf ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user