Unexpected behaviour when resetting an SC_CTHREAD

[xilef97]

Given the following CTHREAD:

 

#include <iostream>
#include <systemc>

using namespace sc_core;

struct ResetBug : sc_module {
    sc_in<bool> clock{"clock"};
    sc_in<bool> reset{"reset"};

    SC_CTOR(ResetBug) {
        SC_CTHREAD(work, clock.pos());
        reset_signal_is(reset, true);
    }

    void work() {
        std::cout << "resetting, reset=" << reset.read() << std::endl;
        for (;;) {
            wait();
            std::cout << "working" << std::endl;
        }
    }
};

int sc_main(int, char *[]) {
    ResetBug bug{"bug"};
    sc_buffer<bool> reset{"reset"};
    sc_clock clock{"clock"};

    bug.clock(clock);
    bug.reset(reset);

    constexpr int N = 4;
    reset = true;
    for (int i = 0; i < N; ++i) {
        sc_start(clock.period());
        reset = false;
    }

    reset = true;
    for (int i = 0; i < N; ++i) {
        sc_start(clock.period());
        reset = false;
    }

    return 0;
}

When executing this, the output is:

resetting, reset=1
working           
working           
working           
resetting, reset=1
resetting, reset=0
resetting, reset=0
resetting, reset=0

 

I don't understand why the CTHREAD keeps getting reset, even though reset is constantly 0/false. When N is set to 3 instead of 4, the result is also weird, but in a different way:

resetting, reset=1
working           
working           
working           
working           
working           

As you can see, the reset doesn't happen at all, which also doesn't seem right. All of this is with SystemC 3.0.0.

When changing the reset-signal to an sc_signal, it works as expected. But in my actual code, I (think that I) am forced to use sc_buffers. Either way, I don't think this behaviour is in accordance with the standard, where it seems that only the level of the reset signal matters.

Is this a bug? Or am I misunderstanding something? Does the reset have to be an sc_signal and not an sc_buffer?

 

Kind regards.