AMDG Roman Morokutti wrote:

...

See https://svn.boost.org/trac/boost/ticket/2602.

Thank you for this hint. As I can tell, this error is still present in 1.39. The patch didn't ease the problem at all because the code now compiles but fails to link due to symbol referencing errors. Bummer!

Are you linking to the thread library? In Christ, Steven Watanabe

AMDG Roman Morokutti wrote:

...

Are you linking to the thread library?

Hi Steven,

which one? There isn't any thread*.so.

Well, actually it's libboost_thread*.so

I am afraid that the thread library didn't build. I'll try to build the thread library separately. Thank you again for your hint.

If you check the ticket again, I've attached a fix that works a little bit better than the previous fix. The library compiles fine for me with that patch the current trunk. For reference bash-3.2$ CC -V CC: Sun C++ 5.9 SunOS_i386 2007/11/15 In Christ, Steven Watanabe

Roman Morokutti writes:

The code sample I used is from the boost documentation of the thread's library at:

http://www.boost.org/doc/libs/1_39_0/doc/html/thread/time.html

Here's the code:

int main(int argc, char** argv) {

boost::system_time const timeout = boost::get_system_time() + boost::posix_time::milliseconds(500);

extern bool done = true; extern boost::mutex m; extern boost::condition_variable cond;

boost::unique_lockboost::mutex lk(m); while (!done) { if (!cond.timed_wait(lk, timeout)) { throw "timed out"; } }

return (EXIT_SUCCESS); }

But as with the code provided on the net (see link above) where the variables (done, m, cond) are specified with extern, the linker always moaned that it couldn't resolve those symbols. So IMHO this example is not well suited for a standalone example.

If you declare variables "extern" at block scope then you need to provide a declaration at global scope too. The point of declaring them extern in the example is to say that these variables are accessible to, and used by, code elsewhere in the system. In particular, another thread will lock the mutex, set done to true and then notify the condition variable. Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

Roman Morokutti writes:

Anthony Williams wrote:

...

If you declare variables "extern" at block scope then you need to provide a declaration at global scope too.

The point of declaring them extern in the example is to say that these variables are accessible to, and used by, code elsewhere in the system. In particular, another thread will lock the mutex, set done to true and then notify the condition variable. Thank you for your explanation, Anthony.

You're welcome.

As I am relatively new to threading, I have another question regarding your example:

Are those variables considered to be for thread local storage. And if, would it be preferable then to use the 'extern' specifier in general?

Thread local storage is manifested in boost with boost::thread_specific_ptr. It's use should be limited to globals (or things that are effectively globals) where each thread must have its own copy. Condition variables, mutexes and the "done" variable from this example are used to communicate between threads, so must be accessible to all threads concerned. Thread local storage is thus a bad idea. The "extern" specifier was trying to convey the idea that these variables are accessible from elsewhere. In general there is very little reason to use extern in practice --- just declare you variables in a shared header, for example.

The problem for me (as a novice) on this example is, that it is shown in a very isolated context.

It was trying to demonstrate a specific feature (using timed wait for a condition variable), not provide a full-featured example of condition variable usage.

When will the patches for the Sun Compiler be integrated into the trunk. For me, I use the CC 5.10 version, these patches worked well.

I will look over them today. Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

Anthony Williams wrote:

Anthony Williams writes:

...

Roman Morokutti writes:

...

When will the patches for the Sun Compiler be integrated into the trunk. For me, I use the CC 5.10 version, these patches worked well. I will look over them today.

I have applied the patch to trunk.

Anthony Thank you for your support. I will appreciate your library.

-Roman