Thanks, Justin. We will look into automic_int64 shortly. John
On 4/23/15 9:32 AM, Justin Swanhart wrote: > 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] > <mailto:[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] >> <mailto:[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] <mailto:[email protected]> >> https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users >> >> >> _______________________________________________ >> FastBit-users mailing list >> [email protected] <mailto:[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
