thread-safety analysis tool?
Does the Studio toolset include anything like a static thread-safety
analysis? I'm thinking of something that would precede even the use
of lock_lint and Data Race Detection Tool.
I'm building a complicated multi-threaded application, and frankly it's
a pain to go looking up every routine I might call to verify its MT-safe
characteristics. I'm also a bit nervous about calling libraries whose
source code I don't control. It would be a Good Idea (TM) if there were
a tool that could crawl my source code and tell me what library routines
I'm calling that might not be totally thread-safe according to their man
pages. The tool could classify them as MT-Safe, Async-signal-safe, etc.
Then I could concentrate my development time on just those routines that
do need my attention.
Think of this as a kind of intermediate lint analysis, halfway in
complexity between lint itself and lock_lint. Yes, it would be an
imperfect analysis, but it would be better than nothing.
Desired options:
(1) Invest some effort in code-path analysis, to reduce the number of
false positives by ignoring routines called by the main thread before
any other threads are spawned, or called only by one thread.
(2) Analyze each library this program links to, first to simply report
all non-thread-safe APIs being called from the library, and then
potentially to analyze which routines from the library actually
get called (perhaps recursively) from my code, again to reduce the
number of false possitives. One can imagine an option to use an
associated descriptive file, akin to a lint library, to assist in
this process.
(3) Have options to include in the analysis particular libraries that
might be linked to at run time to via dlopen(), that the tool wouldn't
find by simple static analysis.
(4) Thread-safety profiles could be developed for alternative environments,
for example for different versions of Solaris, or for different versions
of Linux. This would assist greatly in porting programs.
Complications:
(1) Some routines might be thread-safe they way they are used by a
single thread; see what the man page has to say about readdir()
and readdir_r(), for instance.
(2) Some routines might be thread-safe as individual functions, but
their use with other routines must be carefully coordinated so as
not to confuse shared state. An example would be calling openlog()
and closelog() from different threads and still expecting syslog()
to work throughout.
Has anyone thought of such a tool before?
