Hi, Jilong,

You are absolutely right with your analysis.  The core problem you see is
that the read operation of sharedInt64 is not synchronized.  What we have
been counting on is that the read operation of a 64-bit integer is an
atomic operation.  This is true on all 64-bit CPUs I know of.  I'd be happy
to be corrected if anyone on the mailing list has more information on this.

If the read operation is atomic, then there is no need to another level of
guard for synchronization.  However, it is possible that you are using a
32-bit CPU, in which case, the read operation of a 64-bit integer is not an
atomic operation.  We should add a conditional compilation option to enable
a mutex lock in the read operator of sharedInt64 and sharedInt32.  We will
do this in the next few days.

Thanks.

John

On Thu, Apr 23, 2015 at 4:02 AM, wang jilong <[email protected]> wrote:

> Hi John,
>
> A. As of fastbit 1.3.8, class sharedInt64 in util.h, is implemented with
> multi-thread-synchronized, on all write-operators (++, +=, +-, --).
> However, the read-operator ()  is not synchronized.
>
> B. ibis::fileManager::totalBytes is a sharedInt64 object. It is used in
> the constructor ibis::fileManager::storage::storage(size_t n).
>
> C. The method "ibis::array_t<T>::reserve(size_t n)" uses
> ibis::fileManager::storage::storage(...).
>
> D. It seems to me that could lead to allocating more memory than
> ibis::fileManager::maxBytes. Is it potentially risky?
>
> E. C++ is very tricky to me, and have not touched for a while, So forgive
> me if I made obvious error above.
>
> (BTW, I am working on a mysterious crash related to JNI around fastbit
> 1.3.8. I found crashes around "ibis::array_t<T>::reserve(size_t n)")
>
> Thanks
>
> Jilong Wang
> _______________________________________________
> 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

Reply via email to