Jump to content
thundium

Possible to abort/terminate an b_transport() call?

Recommended Posts

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×