Possible to abort/terminate an b_transport() call?

[thundium]

Hi Everyone:

An b_transport() can be blcoked for whatever time. Is that possible to abort/terminate an b_transport() call (I am at LT level)?

For example I have three modules A,B,C

A--> B(Thread) --> C

A can send commands to B.

B have a thread making operation to C (C can block B for some time).

Now if B is blocking by b_transport() call to C, I will A can terminate that b_transport() call with a command.

Is that possible? Or is there any good way to work around it?

Thank you very much

BR/Thundium

[apfitch]

One answer is "no" - blocking transport can indeed block "forever" and that would presumably represent a functional error in your model.

Another possible answer is: for maximum simulation speed, ideally you should not block (wait) inside b_transport. Any waits would be in the threads that called b_transport.

Time modelling can be handled either by explicit synchronization between the master threads; or by using the quantum, together with timing annotation in the b_transport function call (again with the option of explicit synchronization between threads if ordering of operations is required).

It's an irony of LT modelling that it works fastest if you don't call wait in b_transport!

Perhaps other people can chip in with some other opinions...

kind regards

Alan

[Philipp A Hartmann]

Of course, Alan is right. You may have a functional error in your model, if B is blocked indefinitely. But of course this depends on what you are modelling.

In SystemC 2.3, you can use the new process control functions (kill, reset, throw_it), to interrupt a blocked thread. See section 5.6.6 of IEEE Std. 1666-2011.

For sending custom "interrupts", a user-defined throw_it may be the most appropriate solution. But beware, that your models may not be exception-safe and can leak resources or invalidate internal invariants if not coded correctly.

SC_THREAD(A);
SC_THREAD(;
sc_process_handle B_handle = sc_get_current_process_handle();
//...
// in A():
B_handle.throw_it( my_exception() );

// in B()
try {
 C_socket->b_transport( ... ); // blocked by a wait internally
} catch ( const my_exception& ex ) {
 // do some cleanup
}

Similarly, you need to make sure, that C can cope with being interrupted by an exception!

Greetings from Oldenburg,

Philipp

[thundium]

Hi Philipp:

Do you think if it is possible that I write some Code to realize that "try,catch" function with SystemC 2.2 ?

Of course, Alan is right. You may have a functional error in your model, if B is blocked indefinitely. But of course this depends on what you are modelling.

In SystemC 2.3, you can use the new process control functions (kill, reset, throw_it), to interrupt a blocked thread. See section 5.6.6 of IEEE Std. 1666-2011.

For sending custom "interrupts", a user-defined throw_it may be the most appropriate solution. But beware, that your models may not be exception-safe and can leak resources or invalidate internal invariants if not coded correctly.

SC_THREAD(A);
SC_THREAD(;
sc_process_handle B_handle = sc_get_current_process_handle();
//...
// in A():
B_handle.throw_it( my_exception() );

// in B()
try {
 C_socket->b_transport( ... ); // blocked by a wait internally
} catch ( const my_exception& ex ) {
 // do some cleanup
}

Similarly, you need to make sure, that C can cope with being interrupted by an exception!

Greetings from Oldenburg,

Philipp

[Philipp A Hartmann]

Do you think if it is possible that I write some Code to realize that "try,catch" function with SystemC 2.2 ?

Not without changing core parts of the kernel.

[David Black]

Of course, Alan is right. You may have a functional error in your model, if B is blocked indefinitely. But of course this depends on what you are modelling.

In SystemC 2.3, you can use the new process control functions (kill, reset, throw_it), to interrupt a blocked thread. See section 5.6.6 of IEEE Std. 1666-2011.

For sending custom "interrupts", a user-defined throw_it may be the most appropriate solution. But beware, that your models may not be exception-safe and can leak resources or invalidate internal invariants if not coded correctly.

SC_THREAD(A);
SC_THREAD(;
sc_process_handle B_handle = sc_get_current_process_handle();
//...
// in A():
B_handle.throw_it( my_exception() );

// in B()
try {
 C_socket->b_transport( ... ); // blocked by a wait internally
} catch ( const my_exception& ex ) {
 // do some cleanup
}

Similarly, you need to make sure, that C can cope with being interrupted by an exception!

Greetings from Oldenburg,

Philipp

Assuming you have access to the targets, you could also put try/catch around the wait(s) and ensure add catch code to ensure a graceful exit. This would preclude using imported targets though. Also, you would need to consider any inferred wait(s) such as fifo.read() that might be present. The more you think this through, the messier it gets. In general, I would avoid exceptions.

As Alan points out, you really want to avoid blocking because it degrades simulation performance.