Hi, Andreas,
Thanks for your patience, we have a fix for the threading problem
detected by your sample code. Please download the current version
(SVN revision 324) of the code from the SVN repository <svn checkout
https://codeforge.lbl.gov/anonscm/fastbit> and give it a try when you
get the chance. The problem was a due to a coding error which causes
a program to not check a critical flag and performing extra unlock
operations.
John
On 9/20/2010 6:20 AM, Andreas Streichardt wrote:
> Hi,
>
> as seen in Jans mail we are analyzing fastbits memory usage a bit more in
> depth.
>
> We have a case where we first select a complete partition into memory and then
> conduct several subselects on it.
>
> It seems there are some locking bugs somewhere inside fastbit which result in
> a locked filemanager::clear().
>
> Simplified testcase attached including helgrind logs:
>
> somedata.log:
> x.cc:
>
> in_memory_select=tab->select("a,b,c","c IN (1)");
>
> alldata.log:
> x.cc:
>
> in_memory_select=tab->select("a,b,c","c IN (1,2)");
>
> (will select all rows).
>
> As you can see in alldata.log there are multiple locking errors and the
> "fileManager::clear -- completed with xx" message is completely missing. When
> increasing fastbits loglevel you will see that it is locked (as indicated by
> helgrind).
>
> Any idea what is happening there?
>
> Kind regards,
>
> Andreas Streichardt
>
>
>
> _______________________________________________
> FastBit-users mailing list
> [email protected]
> https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
_______________________________________________
FastBit-users mailing list
[email protected]
https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
