stdcxx-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (STDCXX-536) allow thread safety tests to time out without failing
Date Thu, 08 May 2008 17:36:12 GMT

    [ https://issues.apache.org/jira/browse/STDCXX-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595332#action_12595332
] 

vitek edited comment on STDCXX-536 at 5/8/08 10:34 AM:
--------------------------------------------------------------

Okay, I submitted an initial patch to remove the rw_ prefix from test local option variables.
See  [r654561|http://svn.apache.org/viewvc?rev=654561&view=rev]. I'll submit a new patch
when we make some decisions about what to do with the issues you just brought up.

As for those issues...

# From memory the only issue with using alarm() in a threaded program is that you have no
control over which thread will get the signal. This can be a problem is some threads in your
program ignore signals, and the signal is delivered to one of those threads.
# I have no problem with that provided we can decide how we want to solve #1 above.
# I considered doing something like this, but it seemed like unnecessary optimization. As
for the type of the timeout flag, it  should probably be changed to {{volatile sig_atomic_t}}
if we are going to use {{alarm()}}.

Having the main thread sleep for the timeout period is not really a good solution. If the
timeout is 60 seconds, but the threads complete in 5, the main thread would waste 55 seconds
waiting for the timeout to expire. It also has the problem that it won't work with single
threaded builds.

I have considered several possible implementations, and I don't see many options that do everything
we would like. The two big issues are single threaded builds and being able to use the timeout
with threads that are not explicitly joined by the thread creation function. The second issue
is not critical, but it seems a bit kludgey to not support timeouts consistently regardless
of what parameters you pass to {{rw_thead_pool()}}.

One option would be to pass some context data to the thread and let the thread decide if it
is time to exit on its own. The context could include the 'drop dead time' for the thread
and then the thread could check the current time against that. Unfortunately that moves more
logic into {{thread_func}} and {{rw_thread_pool_timeout_expired()}}. Another option would
be to build a timer queue and . This would require that the test library always be built with
threads so that we could spawn a thread to service the timers.


      was (Author: vitek):
    Okay, I submitted an initial patch to remove the rw_ prefix from test local option variables.
See  [r654561|http://svn.apache.org/viewvc?rev=654561&view=rev]. I'll submit a new patch
when we make some decisions about what to do with the issues you just brought up.

As for those issues...

1. From memory the only issue with using alarm() in a threaded program is that you have no
control over which thread will get the signal. This can be a problem is some threads in your
program ignore signals, and the signal is delivered to one of those threads.

Having the main thread sleep for the timeout period is not really a good solution. If the
timeout is 60 seconds, but the threads complete in 5, the main thread would waste 55 seconds
waiting for the timeout to expire. It also has the problem that it won't work with single
threaded builds.

I have considered several possible implementations, and I don't see many options. One option
would be to pass some context data to the thread and let the thread decide if it is time to
exit on its own. The context could include the 'drop dead time' for the thread and then the
thread could check the current time against that. Unfortunately that moves more logic into
the thread_func and into the function used to poll timeouts Another option would be to build
a timer queue. This would require that the test library always be built with threads so that
we could spawn a thread to service the timers.

2. I have no problem with that provided we can decide how we want to solve #1 above.
3. I considered doing something like this, but it seemed like unnecessary optimization. As
for the type of the timeout flag, it  should probably be changed to {{volatile sig_atomic_t}}
if we are going to use {{alarm()}}.
  
> allow thread safety tests to time out without failing
> -----------------------------------------------------
>
>                 Key: STDCXX-536
>                 URL: https://issues.apache.org/jira/browse/STDCXX-536
>             Project: C++ Standard Library
>          Issue Type: Improvement
>          Components: Tests
>    Affects Versions: 4.2.0
>            Reporter: Martin Sebor
>            Assignee: Travis Vitek
>             Fix For: 4.2.2
>
>         Attachments: stdcxx-536.patch
>
>   Original Estimate: 3h
>          Time Spent: 4h
>  Remaining Estimate: 0h
>
> The newly added thread safety tests (and possibly some of the existing ones) tend to
run for a long time, consuming a lot of CPU cycles, and sometimes even failing due to a timeout
(currently 300 seconds in nightly builds). It would be useful to provide a mechanism such
as a command line option whereby the tests' runtime could be limited without necessarily causing
them to fail when the amount of time is exceeded. One way to do it would be for each test
to set an alarm in response to this command line option and in handler for the alarm set a
flag that each thread would check at each iteration of its loop to see if it should break.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message