C#

Jayamanickam wrote:

but it will not run a setup file different sysytem

[Test]
public void MultipleReaders()
{

        using (concurrencyTester = new ConcurrencyTester())
        {
            this.Given(c => c.new_reader_writer_lock())
                .And(c => c.i_start_read_operation(1))
                .And(c => c.i_wait_till_read_operation_is_pending(1))
                .And(c => c.i_start_write_operation(1))
                .And(c => c.i_start_read_operation(2))
                .And(c => c.i_wait_till_read_operation_is_pending(2))
                .And(c => c.i_start_write_operation(2))
                .When(c => c.release_read_operations(new[] { 1, 2 }))
                .And(c => c.release_write_operations(new[] { 1, 2 }))
                .And(c => c.wait_for_test_end())
                .Then(c => c.write_operations_should_not_intersect_with_read_operations())
                .And(c => c.write_operations_should_not_intersect_with_other_write_operations())
                .BDDfy();

            concurrencyTester.Marks.DumpTimeline();
        }
}

void i_start_write_operation(int number)
{
    concurrencyTester.Start(
                     c =>
                     {
                         readerWriterLock.EnterWriteLock();
                         using (concurrencyTester.Marks["Write"].BeginSection())
                         {
                             concurrencyTester.Events[WriteOperationPending, number].Wait();
                         }
                         readerWriterLock.ExitWriteLock();
                     }, "Write Operation #{0}", number);
}

void write_operations_should_not_intersect_with_read_operations()
{
    foreach (var intersect in this.concurrencyTester.Marks["Write"].Sections.SelectMany(readSection => readSection.Relations.Intersect))
    {
        intersect.Mark.Name.ShouldNotBe("Read");
    }
}

Thomas Maierhofer (Tom) wrote:

this.Given(c => c.new_reader_writer_lock())
.And(c => c.i_start_read_operation(1))
.And(c => c.i_wait_till_read_operation_is_pending(1))
.And(c => c.i_start_write_operation(1))
.And(c => c.i_start_read_operation(2))
.And(c => c.i_wait_till_read_operation_is_pending(2))
.And(c => c.i_start_write_operation(2))
.When(c => c.release_read_operations(new[] { 1, 2 }))
.And(c => c.release_write_operations(new[] { 1, 2 }))
.And(c => c.wait_for_test_end())
.Then(c => c.write_operations_should_not_intersect_with_read_operations())
.And(c => c.write_operations_should_not_intersect_with_other_write_operations())
.BDDfy();

Thomas Maierhofer (Tom) wrote:

So it should become very easy to write concurrency tests with this framework

Bastard Programmer from Hell
If you can't read my code, try converting it here[^]

void i_start_write_operation(int number)
{
    concurrencyTester.Start(
                     c =>
                     {
                         readerWriterLock.EnterWriteLock();
                         using (concurrencyTester.Marks["Write"].BeginSection())
                         {
                             concurrencyTester.Events[WriteOperationPending, number].Wait();
                         }
                         readerWriterLock.ExitWriteLock();
                     }, "Write Operation #{0}", number);
}

void release_write_operations(int[] numbers)
{

    foreach (var number in numbers)
    {
        concurrencyTester.Events[WriteOperationPending, number].Set();
    }

}

.When(c => c.release_read_operations(new[] { 1, 2 }))
.And(c => c.release_write_operations(new[] { 1, 2 }))

Thomas Maierhofer (Tom) wrote:

Behavior Driven Tests have all the same structure:

Thomas Maierhofer (Tom) wrote:

Our old approach of concurrency testing does not fit in very well:

Thomas Maierhofer (Tom) wrote:

You can't split this up semantically in Given/When/Then

Thomas Maierhofer (Tom) wrote:

Without the concurrency tester this is much harder to test.

Bastard Programmer from Hell
If you can't read my code, try converting it here[^]

Quote:

The only thing you wouldn't have is the path of the threads that are depending on another - that's the kind of dependency I try to avoid altogether.

Quote:

Thomas Maierhofer (Tom) wrote:
Our old approach of concurrency testing does not fit in very well:
I don't see the difference; either you .And(bla) or Assert(bla). As soon as it is repeated on each line, it becomes noise during reading.

Thomas Maierhofer (Tom) wrote:

If I want to test a synchronization primitive - here a Reader Writer lock, how
can you avoid thread dependencies?

Thomas Maierhofer (Tom) wrote:

Imagine a unit test (in pseudocode) that can perform the same test from scratch.

Thomas Maierhofer (Tom) wrote:

BDD is a slightly different approach. Love it or hate it.

Bastard Programmer from Hell
If you can't read my code, try converting it here[^]

Quote:

Thomas Maierhofer (Tom) wrote:
If I want to test a synchronization primitive - here a Reader Writer lock, how
can you avoid thread dependencies?There's no silver bullet there, no single solution that will work in all cases. Instead of waiting for the reader-thread you might want to look at a queue.

Thomas Maierhofer (Tom) wrote:

Sorry you totally misunderstood me. If you are DEVELOPING a Reader Writer Lock
Class

Bastard Programmer from Hell
If you can't read my code, try converting it here[^]

Thomas Maierhofer (Tom) wrote:

Assuming I am the guy who developed this class, how would I test this class?

Bastard Programmer from Hell
If you can't read my code, try converting it here[^]

Sascha Lefévre wrote:

.... other than I can't see how ${fps} and ${video_bitrate} should be replaced by some value.

objPlayerProcess.StandardInput.WriteLine("osd_show_property_text ${fps}" + "(FrameRate)" + objPlayerProcess.StandardInput.NewLine + "osd_show_property_text ${video_bitrate}" + "(BitRate)");