[variant] variant member function apply_visitor( visitor ) thread-safe?
Hello, Is the apply_visitor() method per se thread-safe, meaning, if i have variant object, and i visit it from different threads at same time, and if i assume the visitor i write is thread-safe, my question is about the machinery of apply_visitor() itself, is it thread-safe? regards,
AMDG Hicham Mouline wrote:
Is the apply_visitor() method per se thread-safe, meaning, if i have variant object, and i visit it from different threads at same time, and if i assume the visitor i write is thread-safe, my question is about the machinery of apply_visitor() itself, is it thread-safe?
The apply_visitor function itself does not modify the variant in any way, such usage ought to be thread-safe. In Christ, Steven Watanabe
Hicham, my only concern would be to evaluate how the variant behaves in MT environment. Especially if the implementation uses VTable idiom to avoid additional level of indirection. In that case if you instantiate variants containing the same type from 2 threads at a time it might get into race condition. VTable in Variants was described in the article by Andrei Alexandrescu on how to implement discriminated unions (published in DDJ) and he suggested to use VTable to avoid additional indirection for the sake of performance. Here are the links: http://www.ddj.com/cpp/184403821 http://www.ddj.com/cpp/184403828 http://www.ddj.com/cpp/184403834 Would be really interesting to get an answer from developers and a doc statement, on which MT guarantees boost::variant provides. Best Regards, Ovanes On Mon, Sep 8, 2008 at 4:48 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
Hicham Mouline wrote:
Is the apply_visitor() method per se thread-safe, meaning, if i have variant object, and i visit it from different threads at same time, and if i assume the visitor i write is thread-safe, my question is about the machinery of apply_visitor() itself, is it thread-safe?
The apply_visitor function itself does not modify the variant in any way, such usage ought to be thread-safe.
In Christ, Steven Watanabe
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Steven, so you mean there are no VTable fakes inside as it is suggested by Andrei and in fact an additional numeric type identifier is stored? Which type from the type list is stored? Thanks, Ovanes On Mon, Sep 8, 2008 at 5:23 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
Ovanes Markarian wrote:
my only concern would be to evaluate how the variant behaves in MT environment. Especially if the implementation uses VTable idiom to avoid additional level of indirection.
Boost.Variant uses a switch statement to dispatch.
In Christ, Steven Watanabe
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
AMDG Ovanes Markarian wrote:
so you mean there are no VTable fakes inside as it is suggested by Andrei and in fact an additional numeric type identifier is stored? Which type from the type list is stored?
At the lowest level, boost::variant<std::string, int> (e.g.) looks something like: class variant { boost::aligned_storage< max(sizeof(std::string), sizeof(int)), lcm(alignment_of<std::string>::value, alignment_of<int>::value)> buffer_; int which_; }; apply_visitor is implemented something to the effect of switch(which_) { case 0: return(f(*static_cast<std::string*>(buffer_.address()))); case 1: return(f(*static_cast<int*>(buffer_.address()))); } In Christ, Steven Watanabe
On Mon, Sep 8, 2008 at 5:39 PM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
Ovanes Markarian wrote:
so you mean there are no VTable fakes inside as it is suggested by Andrei and in fact an additional numeric type identifier is stored? Which type from the type list is stored?
At the lowest level, boost::variant<std::string, int> (e.g.) looks something like:
class variant { boost::aligned_storage< max(sizeof(std::string), sizeof(int)), lcm(alignment_of<std::string>::value, alignment_of<int>::value)> buffer_; int which_; };
apply_visitor is implemented something to the effect of
switch(which_) { case 0: return(f(*static_cast<std::string*>(buffer_.address()))); case 1: return(f(*static_cast<int*>(buffer_.address())));
}
Ok! That's great. This is what I was concerned of. So variant provides basic thread safety guarantee.
participants (3)
-
Hicham Mouline -
Ovanes Markarian -
Steven Watanabe