As it turns out, this multithreaded vis isn't safe. The problem lies with the autosave feature:

Each thread processes one portal at a time, that's why the fullvis is sped up on the whole the more threads a machine has. However, as we know, not all portals take the same amount of time - especially towards the end, their processing time increases greatly, some of them can even take days. The autosave option is geared for single-threaded processing, so it doesn't take into account which portals are done and which are still being processed on the other threads when saving the state. Therefore, pausing the process (ctrl+c) will leave these portals (that were being processed but couldn't be finished yet) open, so to speak. This will eventually lead to a situation where vis reaches the end of the processing line, but can't wrap up the entire thing properly because there're still those 'undone' portals in-between. It will then stop with a "portal not done" warning and the state file will be corrupted.

This means the multithreaded vis tool can only be used (more or less) safely if one leaves the process run from start to finish. Maps that take longer and thus have to rely on the autosave function should not be fullvised with this tool. 

Oh. OK, that explains why I wasn't able to VIS your map for you then (my resumes kept failing). Damn. 

Well, the source code is on Quaketastic so I'll see about making some time to look into it. It shouldn't be too difficult.

The solution, probably, is to turn off the threading when the autosave is ready to go, wait until the last portal finishes, save, and then start them all up again. We'll see... 

Ahoi,

aroused by Spirit's coding bounties over at quaddicted.com I thought I might take a look this one.

Honestly I haven't really dived into the code much. However judging by the comments I thought I try some blind thread synchronization upon saving.

Here is my first appalling version:

http://user.cs.tu-berlin.de/~tuna/WVis_thread_test.zip

I'm not even sure how to trigger the issue described. I tried ctrl-c-ing and continuing with the unmodified version and I didn't encounter the "warning" message..

If you have precise instructions how to make it fail please let me know.

Also feedback if the issue has changed or improved with my version is highly appreciated. 

Hooray! Thanks man. I took a few shots at it but always came up short. 

Could somebody explain how to properly test this? 

I think just get a map that takes a long time to VIS and stop/start it repeatedly. 

I tried gmsp3tw and it worked very well. 

But can you get a failure with the old version? The old version worked most of the time - until it didn't. :) 

I set the -savetime to 10 and interrupted it a lot. Got the error in return at the end. 

I set the -savetime to 10 and interrupted it a lot. Got the error in return at the end. 

Release the src, please. 

I wanted to wait for more feedback - or at least for no negative results. I will send the patch to Spirit later today or tomorrow when I have access to the machine again. I hope he can review it and decide whether it qualifies for the bounty or not :-) 

 

http://www.quaddicted.com/quaddictedcom/first-bounty-claimed-multi-thread-vis-bug-fixed/ 

http://www.quaddicted.com/tools/wvis_20100117.7z
sorry, zip would not work 

Call for testing! Please re-download the test version from my location above. Its a newer version which should be more efficient and hopefully also has the bug fixed. 

When I use -nosave, I don't get %/time interval updates from the "full" part of the vis process. 

Updated the .zip file. I think this bug was also in the original version?

Now there is also the chance that if you have a corrupted .vis file that it gets repaired when it gets loaded. 

It indeed loads my corrupted state file and seems to be continuing the process normally. 

Is this the 'idle' or the 'reset' version? 

This should be the 'right' version: No thread synchronization is done. Instead undone portals are marked as such instead upon saving.

If no bugs are found this should become the recommended version.

In the end the fix could probably be done by changing one line. But I think its ok to fix some other things while we are at it. 

Nice work, tuna! 

I'm currently testing it on my coag map. The ultimate goal would be to get all portals done except for the long one, thus making the PVS data as complete as possible. Problem is that I can't tell what's going on as the -verbose display isn't as clear as in single-thread mode. Or dunno.. 

Hm. Not sure what the verbose messages are supposed to output. In theory just keep an eye on the CPU usage. When the "Full" Vis step is only using one core you are there.. Might be difficult to spot when you are on a single core CPU. When the task manager displays the threads per process you might keep an eye on them..