#2 Thread safety of YARP

[Alejandro R. Mosteo]

I'm seeing some hangs when two threads call Network::connect at the same time. So I'd like to know the thread safety level of yarp. Mostly:

Are the static members of Network thread safe? (I guess not?)

I presume that two independent ports can be used safely by two different threads.

Can two threads write to a same port? (I guess so).

Thank you in advance.

[Paul Fitzpatrick]

The static members of Network should in principle be thread safe. Two independent ports should be safely usable by two different threads.

Two threads accessing the same Port or BufferedPort object must in general do so mutually exclusively.

Can you give a test case that provokes the hangs you are seeing?
-Paul

[Alejandro R. Mosteo]

Hi Paul,

You're right, these calls to Network::connect do not give problems in a debian etch box. I'm however seeing many odd effects in a 8.10 ubuntu box, do you have any other reports on this? Among the things I'm observing are (with both yarp 2.2.0 and 2.2.2):

Several 'make test' tests fail; ModuleTest sometimes hangs; PortCoreTest segfaults more often than not; PortTest also segfaults albeit more sparingly; other times it runs away on memory until all is exhausted an gets killed.

Then, one program which works without issue in debian, apparently works well also in ubuntu but the calls to Port.Read, even if blocking, consume 100% cpu. Valgrind inspection shows that this burning loop is deep in libACE in calls related to semaphores. I could attach a debug from callgrind if you're interested.

I don't have customized this box; it's all stock libraries but for yarp and player 2.0.4... but I have no idea if something is botched in my system or all ubuntus 8.10 are that problematic. Here are the libraries in use just in case:

$ ldd `which yarp`
linux-gate.so.1 => (0xb7f5c000)
libACE-5.6.3.so => /usr/lib/libACE-5.6.3.so (0xb7dde000)
librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7dd5000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7dd0000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7ce1000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7cbb000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7cac000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7b4e000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7b35000)
/lib/ld-linux.so.2 (0xb7f42000)

[Paul Fitzpatrick]

If "make test" isn't working reliably on your ubuntu box, then something is badly broken. However, the shared library dependencies look fine.

There are lots of options in how ACE is compiled, so it could be that there is a mismatch between the Ubuntu package and YARP's expectations. I haven't heard any reports of problems from Ubuntu users though.

You can find a precompiled version of yarp and a test program called "harness_os" here:
http://eris.liralab.it/download/yarp/linux-i386/

If you run harness_os like this:
./harness_os regression
or
./harness_os verbose regression

it will basically do what make test does, except with more verbose output. Could you try that? If it has no trouble, that points to a compilation problem.

Another thing to try is just to run the harness_os compiled already on your machine (same directory as the yarp executable) and attach its output here.

Finally, we do have a procedure of last resort for mysterious ACE troubles. See:
http://eris.liralab.it/wiki/ACE4YARP

[Alejandro R. Mosteo]

My locally built harness_os, complaining about failing waits for semaphores

[Alejandro R. Mosteo]

File Added: harness.err.log.gz

[Alejandro R. Mosteo]

This is the harness_os output downloaded from the given URL, which seems OK.

[Alejandro R. Mosteo]

File Added: harness.ok.log.gz

[Alejandro R. Mosteo]

I have uploaded two harness_os logs, from my locally compiled one and yours. I see that your harness_os has no dependencies on my local yarp or libace, so I guess it is statically linked.

My harness_os indicates that something is wrong with the semaphores (I certainly wasn't running gdb). I guess this is the reason for some busy loop burning cpu.

In any case, I'm interested in statically linking ACE in addition to YARP, so perhaps the best solution for me is to use your ACE4YARP and get rid of both issues (assuming that ACE version will behave fine here).

[Paul Fitzpatrick]

Thanks for the logs. I don't recognize the problem. If you are interested in statically linking ACE, using ACE4YARP is a simple way to do it (just follow the instructions on the wiki page) and given that the harness_os I pointed you at works (which was linked with ACE4YARP) that should get you going.

I am concerned that YARP is not compiling well on a stock Ubuntu install. I'll ping our mailing list to see if others have had similar difficulties. Thanks for reporting this.