thread_safe_ptr class interest request
Hello, I've made a thread_safe_ptr class available at http://codepad.org/PxDEGaFm The idea is to use it like so: std::string data = "Hello world;"; thread_safe_ptr<std::string> data_ptr(&data); void thread1() { data_ptr->resize(3); } void thread2() { *data_ptr = "yeah"; } boost::thread t1(&thread1); boost::thread t2(&thread1); t1.join(); t2.join(); Do you see an obvious show-stopper for me not to continue developping this class? What's still to be done is worry about ownership of objects, my idea is to eventually somewhat model it after boost::shared_ptr that way it's easier to pass those around. When I'll be satisfied with the result, my plan is to "boostify" it (namespaces, license etc) and maybe propose it for inclusion in the smart pointer library. What are your thoughts? Philippe
On Wed, Jul 28, 2010 at 2:44 PM, Philippe Vaucher <philippe.vaucher@gmail.com> wrote:
Hello,
I've made a thread_safe_ptr class available at http://codepad.org/PxDEGaFm
The idea is to use it like so:
std::string data = "Hello world;"; thread_safe_ptr<std::string> data_ptr(&data);
void thread1() { data_ptr->resize(3); }
void thread2() { *data_ptr = "yeah"; }
boost::thread t1(&thread1); boost::thread t2(&thread1); t1.join(); t2.join();
std::stack<int> deq = ...; thread_safe_ptr<std::stack<int> > data_ptr(&data); int pop() { int my_top = data_ptr->top(); data_ptr->pop(); // will this pop my_top? return my_pop; } Unfortunately the interface of a class must be designed to be threadsafe, you can't just bolt on thread safety by locking every member function. Such a wrapper might have some limited use, but it could lead to a false sense of security. Just my 0.2 € -- gpd
2010/7/28 Giovanni Piero Deretta <gpderetta@gmail.com>:
On Wed, Jul 28, 2010 at 2:44 PM, Philippe Vaucher <philippe.vaucher@gmail.com> wrote:
Hello,
I've made a thread_safe_ptr class available at http://codepad.org/PxDEGaFm
The idea is to use it like so:
std::string data = "Hello world;"; thread_safe_ptr<std::string> data_ptr(&data);
void thread1() { data_ptr->resize(3); }
void thread2() { *data_ptr = "yeah"; }
boost::thread t1(&thread1); boost::thread t2(&thread1); t1.join(); t2.join();
std::stack<int> deq = ...; thread_safe_ptr<std::stack<int> > data_ptr(&data);
int pop() { int my_top = data_ptr->top(); data_ptr->pop(); // will this pop my_top? return my_pop; }
Unfortunately the interface of a class must be designed to be threadsafe, you can't just bolt on thread safety by locking every member function. Such a wrapper might have some limited use, but it could lead to a false sense of security.
Just my 0.2 €
I was about to make the same comment, however I noticed there is a thread_safe_ptr::scoped_lock with pointer semantics for such occasions. I think this solution is nice and would happily see it as a part of boost smart pointer or thread libraries. int pop() { thread_safe_ptr< std::stack<int> >::scoped_lock lock(data_ptr); int my_top = lock->top(); lock->pop(); return my_pop; } Yours, Krzysztof Wrzalik
I was about to make the same comment, however I noticed there is a
thread_safe_ptr::scoped_lock with pointer semantics for such occasions. I think this solution is nice and would happily see it as a part of boost smart pointer or thread libraries.
int pop() { thread_safe_ptr< std::stack<int> >::scoped_lock lock(data_ptr); int my_top = lock->top(); lock->pop(); return my_pop; }
Yes exactly, the current code doesn't support this yet but it was in the pipeline. Philippe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 28 July 2010, Philippe Vaucher wrote:
What's still to be done is worry about ownership of objects, my idea is to eventually somewhat model it after boost::shared_ptr that way it's easier to pass those around.
In which case you would wind up with something almost exactly like poet::monitor_ptr: http://www.comedi.org/projects/libpoet/boostbook/doc/boostbook/html/poet/mon... I found the resulting coupling of two orthogonal concepts (automatic locking and shared_ownership) to be unsatisfactory however, resulting in the generic_ptr library in the boost sandbox (undocumented), which allows composition of smart pointer types, plus facilities for writing generic code that manipulates pointers or pointer-like classes. generic_ptr::monitor<T*> m; would be like your thread_safe_ptr<T> and generic_ptr::shared<generic_ptr::monitor<T*> > sm; would be like a shared_ptr with automatic locking. I'm not trying to discourage your efforts however. I just want to make you aware of this code I wrote in case it is useful to you or someone else who wants to take up the problem (I don't spend much time on volunteer programming projects these days, and probably wont ever get around to trying to get any of this into boost). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkxQkUcACgkQ5vihyNWuA4VaYgCg30D6Cut9tgUpe1Ir03a46DPw gcgAn30kWE04F+0moq/eObgdbtxkLXN6 =K3Ph -----END PGP SIGNATURE-----
What's still to be done is worry about ownership of objects, my idea is to eventually somewhat model it after boost::shared_ptr that way it's easier to pass those around.
In which case you would wind up with something almost exactly like poet::monitor_ptr:
http://www.comedi.org/projects/libpoet/boostbook/doc/boostbook/html/poet/mon...
I found the resulting coupling of two orthogonal concepts (automatic locking and shared_ownership) to be unsatisfactory however, resulting in the generic_ptr library in the boost sandbox (undocumented), which allows composition of smart pointer types, plus facilities for writing generic code that manipulates pointers or pointer-like classes.
Interesting, why isn't this up for review? Philippe
participants (4)
-
Frank Mori Hess -
Giovanni Piero Deretta -
Kyku -
Philippe Vaucher