On X86_64 it is atomic if memory is aligned. ARM does not make this guarantee and requires synchronization. I am not sure about POWER, may depend in compiler/flags.
This may be useful: https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html c++11 has an atomic_int64 which may be useful. Sent from my iPhone > On Apr 23, 2015, at 7:02 AM, John Wu <[email protected]> wrote: > > 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
_______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
