Cannot put .o File with Graph Code into .a File
Hi there, while trying to setup the BGL for use in my environment I'm facing a strange behavior when I try to put a C++ object file which contains instanciations of BGL templates into an object library. My environment: - Sun SPARC machine with Solaris 2.7 (SunOS 5.7) - gcc 2.95.2 The problem shows up when I try to put an .o file into a library file. I can reproduce the error with the file adjacency_list.cpp from the BGL's examples directory: $ pwd /home/perbandt/boost_1_28_0/libs/graph/example $ g++ --version 2.95.2 $ g++ -g -I../../../../boost_1_28_0 -c adjacency_list.cpp $ ls -l adjacency_list.o -rw-r--r-- 1 perbandt relman 3367052 Jul 19 18:40 adjacency_list.o $ which ar /usr/ccs/bin/ar $ ar rv libtest.a adjacency_list.o a - adjacency_list.o Bus error When I try a .a file with already one or more .o files in it I get a segmentation fault. With another file that contains instantiations of BGL templates the problem does appear only when it was compiled with the -g option given. Is this a known problem? Seems to me as if ar would have trouble handling the very long symbol names in the .o file. Or is something wrong with my environment? Thanks, Adalbert Perbandt.
Is there anything available or coming in boost::thread to wrap STL containers into thread safe containers? If not, any advice for coding those wrappers efficiently/elegantly or not doing that? If not again, why and how do you deal with the problem then? Thanks, Herve. -- Herve Blanc phone: 1 408 586 6437 fax: 1 408 586 4675 mailto:blanc@san-jose.tt.slb.com NPTest, Inc. 150 Baytech Drive, San Jose, CA 95134-2302, USA http://www.slb.com/semiconductors/
--- In Boost-Users@y..., Herve Blanc <blanc@s...> wrote:
Is there anything available or coming in boost::thread to wrap STL containers into thread safe containers?
No.
If not, any advice for coding those wrappers efficiently/elegantly or not doing that?
Trying to do this is generally a bad idea. Using an internal mutex to protect the class will only allow you to synchronize at the method call level, and most user code will need synchronization around multiple such calls not a single call. Example: my_thread_safe_vector[0] += some_value; if (my_thread_safe_vector[0] > 100) my_thread_safe_vector[0] = 100; The above code is full of race conditions, even if my_thread_safe_vector uses a mutex internally.
If not again, why and how do you deal with the problem then?
Use an external mutex to achieve the proper lock granularity. Example: boost::mutex::scoped_lock lock(my_mutex); my_vector[0] += some_value; if (my_vector[0] > 100) my_vector[0] = 100; There's no race in the above since the external mutex and lock insure the proper granularity for the three calls to the container methods. Bill Kempf
bill_kempf wrote:
--- In Boost-Users@y..., Herve Blanc <blanc@s...> wrote:
Is there anything available or coming in boost::thread to wrap STL containers into thread safe containers?
No.
If not, any advice for coding those wrappers efficiently/elegantly or not doing that?
Trying to do this is generally a bad idea. Using an internal mutex to protect the class will only allow you to synchronize at the method call level, and most user code will need synchronization around multiple such calls not a single call. Example:
my_thread_safe_vector[0] += some_value; if (my_thread_safe_vector[0] > 100) my_thread_safe_vector[0] = 100;
The above code is full of race conditions, even if my_thread_safe_vector uses a mutex internally.
If not again, why and how do you deal with the problem then?
Use an external mutex to achieve the proper lock granularity. Example:
boost::mutex::scoped_lock lock(my_mutex); my_vector[0] += some_value; if (my_vector[0] > 100) my_vector[0] = 100;
There's no race in the above since the external mutex and lock insure the proper granularity for the three calls to the container methods.
Bill Kempf
The "Multithreading and the C++ Type System" article by Andrei Alexandrescu (available @ http://www.informit.com/isapi/product_id~%7BE3967A89-4E20-425B-BCFF-B84B6DEE... ) provides a generic solution to your scenarios as well... the kind of answer I was looking for, am I missing something? Herve. -- Herve Blanc phone: 1 408 586 6437 fax: 1 408 586 4675 mailto:blanc@san-jose.tt.slb.com NPTest, Inc. 150 Baytech Drive, San Jose, CA 95134-2302, USA http://www.slb.com/semiconductors/
--- In Boost-Users@y..., Herve Blanc <blanc@s...> wrote:
bill_kempf wrote:
--- In Boost-Users@y..., Herve Blanc <blanc@s...> wrote:
Is there anything available or coming in boost::thread to wrap STL containers into thread safe containers?
No.
If not, any advice for coding those wrappers efficiently/elegantly or not doing that?
Trying to do this is generally a bad idea. Using an internal mutex to protect the class will only allow you to synchronize at the method call level, and most user code will need synchronization around multiple such calls not a single call. Example:
my_thread_safe_vector[0] += some_value; if (my_thread_safe_vector[0] > 100) my_thread_safe_vector[0] = 100;
The above code is full of race conditions, even if my_thread_safe_vector uses a mutex internally.
If not again, why and how do you deal with the problem then?
Use an external mutex to achieve the proper lock granularity. Example:
boost::mutex::scoped_lock lock(my_mutex); my_vector[0] += some_value; if (my_vector[0] > 100) my_vector[0] = 100;
There's no race in the above since the external mutex and lock insure the proper granularity for the three calls to the container methods.
Bill Kempf
The "Multithreading and the C++ Type System" article by Andrei Alexandrescu (available @ http://www.informit.com/isapi/product_id~%7BE3967A89-4E20-425B- BCFF-B84B6DEED6CA%7D/content/index.asp ) provides a generic solution to your scenarios as well... the kind of answer I was looking for, am I missing something?
Not really missing anything. I've employed similar techniques in my own code, though there are some interesting design choices here that I may find a way to add to Boost.Threads. I thought what you were wanting was something along the lines of full replacements that used internal locking or something along the lines of the solution in this article where you pass in locks. The first is a bad idea, while the second is out of scope for the library. I have, however, been contemplating the inclusion of a locking_ptr<> (a concept I'll attribute to Bjarne, though I've seen others discuss this concept as well and really don't know who was first), but with the ability to hoist the locking level up for larger granularity. The result would be something similar to the ExternallyLocked template from this article. I'm still working out some of the design details, and this has a rather low priority right now, but I am playing with the idea. Bill Kempf
participants (3)
-
Adalbert Perbandt -
bill_kempf -
Herve Blanc