pthread locks being flagged by cilkscreen

pthread locks being flagged by cilkscreen

In our application we have a cilk program that initializes a library,
and then spawns some work off.

Inside the library there are some pthreads.

There are shared data structures that the pthreads and the cilk
strands touch, protected by a lock.

Cilkscreen complains about locks being held at thread boundaries.
(Which BTW should be called strand boundaries, right?)

Each pthread that acquires the lock releases the lock.
Each cilk strand that acquires the lock releases the lock.
But we still get these warnings, even if the cilk strands don't even
touch the lock.

Attached is an example program that shows the problem. In this example, the cilk strands don't even touch the lock.

The output is shown below.

Any advice on how to get cilkscreen to give me a clean bill of health?

-Bradley

$ make check_foo.parallel
/home/bradley/cilkarts/8503/cilk/bin/cilk++ -Wall -W -Werror -g
foo.cilk -o foo.parallel
/home/bradley/cilkarts/8503/cilk/bin/cilkscreen ./foo.parallel

Cannot hold locks at a thread boundary
at 0x400dd3: (/home/bradley/tokusandbox/tokudb/toku/tokudb.2216/src/tests/cilktests/foo.cilk:37,
__cilk_spawn_foo_001+0x55)
called by 0x400f6f:
(/home/bradley/tokusandbox/tokudb/toku/tokudb.2216/src/tests/cilktests/foo.cilk:37,
_Z9cilk_mainQiiPPc+0x41)
called by 0x401253: (_ZN4cilk9main_wrapEQiPv+0x53)
called by 0x7f8ab48645d1: (_Z20cilk_run_wrapper_intQvPv+0x51)
called by 0x7f8ab486670a: (__cilkrts_init_helper+0x5)
holding 1 lock:
0x601ac0

Cannot hold locks at a thread boundary
at 0x7f8ab48663d7: (__cilkrts_free_frame+0x57)
called by 0x400f6f:
(/home/bradley/tokusandbox/tokudb/toku/tokudb.2216/src/tests/cilktests/foo.cilk:37,
_Z9cilk_mainQiiPPc+0x41)
called by 0x401253: (_ZN4cilk9main_wrapEQiPv+0x53)
called by 0x7f8ab48645d1: (_Z20cilk_run_wrapper_intQvPv+0x51)
called by 0x7f8ab486670a: (__cilkrts_init_helper+0x5)
holding 1 lock:
0x601ac0

Cannot hold locks at a thread boundary
at 0x400f6f: (/home/bradley/tokusandbox/tokudb/toku/tokudb.2216/src/tests/cilktests/foo.cilk:37,
_Z9cilk_mainQiiPPc+0x41)
called by 0x401253: (_ZN4cilk9main_wrapEQiPv+0x53)
called by 0x7f8ab48645d1: (_Z20cilk_run_wrapper_intQvPv+0x51)
called by 0x7f8ab486670a: (__cilkrts_init_helper+0x5)
holding 1 lock:
0x601ac0
T7f8ab1dff710 got lock
T7f8ab1dff710 releasing lock
T7f8ab32ff710 got lock
T7f8ab32ff710 releasing lock
3 errors found by Cilkscreen
$ /home/bradley/cilkarts/8503/cilk/bin/cilk++ --version
cilk++ (GCC) 4.2.4 (Cilk Arts build 8503)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

AdjuntoTamaño
Descargar foo.cilk930 bytes
publicaciones de 4 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

I think cilkscreen for Linux is tracking operations by all threads and not only the Cilk thread. The Cilk program itself is run single-threaded so the distinction only matters when the user program creates its own threads. Cilkscreen doesn't know that the lock held at spawn is held by a different thread because normally there wouldn't be more than one thread. On Windows cilkscreen ignores activity by other threads; this code was never added to the Linux version.

Best would be to fix it.

Also it would be helpful if I could supress false positives, the way I can with valgrind.

If I could turn off this kind of error, that would be helpful.

-Bradley

Hello Intel,This is a big problem for us. Can you fix it for linux?

Inicie sesión para dejar un comentario.