ThreadedOptions annotation?

[Scott]

Hello, Alasdair --

I see the following information about using CodePositions in the wiki:

"We can add an option to our test class to specify that Weaver should
stop the first thread at this position.

public class MyListTest {
MyList list;

@ThreadedOptions
public AnnotatedTestOptions getOptions() {
...
CodePosition position =
recorder.inMethod(control.putIfAbsent(null))
.afterCalling(target.contains(null))
return new AnnotatedTestOptions(position);
}"

But I don't see either @ThreadedOptions nor AnnotatedTestOptions
anywhere in the distribution. Is this functionality that has been
removed?

If so, is there any way to to pass a CodePosition to use as a
breakpoint in @ThreadedMain? Or do I need to go the scripted/
interleaved tests route?

thanks,

-- Scott

[Alasdair Mackintosh]

On Mon, May 16, 2011 at 9:52 AM, Scott <spr...@gmail.com> wrote:
> Hello, Alasdair --
>
> I see the following information about using CodePositions in the wiki:
>
> "We can add an option to our test class to specify that Weaver should
> stop the first thread at this position.
>

>   @ThreadedOptions
>   public AnnotatedTestOptions getOptions() {
>     ...
>     CodePosition position =
> recorder.inMethod(control.putIfAbsent(null))
>      .afterCalling(target.contains(null))
>     return new AnnotatedTestOptions(position);
>   }"
>
> But I don't see either @ThreadedOptions nor AnnotatedTestOptions
> anywhere in the distribution.  Is this functionality that has been
> removed?

Hi Scott,

Hmm, it's a while since I wrote that Wiki article. I think it may be
out-of-date.

If you want to control the position where ThreadWeaver stops the first
thread, I think you can do that by using the various methods in
InterleavedRunner. Take a look at InterleavedRunner.interleaveAfter(),
which I think will do what you want.

Let me know if that's not what you need.

Alasdair

[Alasdair Mackintosh]

On Tue, May 17, 2011 at 4:32 PM, Scott Prater <spr...@gmail.com> wrote:
> Hi, Alasdair --
>
> I was able to get a test working using CodePositions.  However, it
> only works if the method being tested is not static.

Hi Scott,

My apologies for giving a slightly misleading answer earlier. I was
concentrating on your question about classloaders rather than about
the details of what you are trying to do.

Unfortunately, Threadweaver doesn't support static methods. This is
because breakpoints are specific to a given object, rather than just
to a method. So if I have:

class Foo {
public void Bar() {
}
}

Foo f;
Foo g;

Then a breakpoint that triggers when f.Bar() is called is not the same
as a breakpoint that triggers when g.Bar() is called.

The reason for doing this is partly a side-effect of the
implementation. For every instrumented object that gets created, we
create a new internal monitor that tracks what happens to that object.
(So when I invoke f.Bar(), I'm recording the method call in f's
monitor. Check out the internal comments in TestInstrumenter.java for
details.

Also, it seemed that having static methods is fairly uncommon in
multithreaded systems, apart from a few simple cases like factories
and so forth.

If you really do want to test a static method, then the best I can
suggest with the current Threadweaver code is to use a
non-instrumented breakpoint. Please see the last section of
http://code.google.com/p/thread-weaver/wiki/UsersGuide.

Hope this helps,

Alasdair

P.S. I can see from your test what you're trying to do. However, if
this is a general-purpose filing system, then I wonder how helpful the
test is going to be? Even if FSBolob can be shown to be threadsafe,
surely there's a risk that another thread (or another process) will
create the parent directory in the middle of a call to
makeParentDirs()?