My purpose is to use 'sc_pending_activity_at_current_time()' to detect if there are other processes scheduled at the current simulation time. So I coded like the following:
1. My main question is: why i always got a '0' from 'sc_pending_activity_at_current_time()'?
The definition of this API is at 'sc_simcontext.cpp', which is very short:
I think the 'c_p->m_runnable->is_empty()' should return a '0' for the first executed kid thread and hence '1' should be returned. But as said, i always got a 0, so what is wrong?

2. My minor question is 'event_mom.notify(100, SC_NS);' does not evoke the 'thread_mom' , strange enough, why?

So my poets, which part of the story does not have a good rhythm, systemc or my code?
Thanks for any help!

---

First the obligatory caution : this isn't really part of the SystemC API. Its not part of the standard and is just a method used in the OSCI implementation. Meaning it may not be portable to other implementation or work in a new rev of SystemC. Something to keep in mind.

The sc_pending_activity_at_current_time() method doesn't do what you are expecting it to do. This is basically for tracking delta cycles created in the current timestamp. So if one of your threads were to cal a wait(SC_ZERO_TIME) you would see this be non-zero following that call.

The delayed notifications you are using are handled differently. They are timed events which will execute at the start of the time (first tick) when they fire. So they don't live in the m_delta_events list that tracks deltas (which is what sc_pending_activity_at_current_time() reports), but instead live in m_timed_events.

I don't recall a good way to get a list of all events in the current time period, and I don't think there is one since thats not the way the scheduler works. The timed events go into what is effectively a time sorted list, and it keeps pulling out the top (soonest) event to execute and executing it if it is in the current time. If the next event is in a later time, it checks to see if any new delta cycles were created and processes those if they exist (repeating this until no delta cycles exist) and then it advances time corresponding to the next timed event. So its not like it grabs all of the events from the current time period and works on them.

Sorry I can't offer you a solution, but maybe you should think about what you are trying to do and solve this explicitly without using the kernel. Thats usually not the right way to go.

Hope that helps.

Jeff

Hallo Jeff:
Your reply is unexpectedly fast and fully right. I give it a closer look at the kernel and see that there are two kinds of queues at the class 'sc_runnable', one push_q and one pop_q. The kernel toggles the 'm_runnable' by dumping all the process handles from push_q to pop_q and zeros push_q. Then it crunches all the handles in the pop_q. The 'm_runnable->is_empty()' will only see if the push_q is empty, hence I always receive a '0'.
Well, my ultimate purpose is to provide a process the information of on-going concurrency, i.e., when is the next soonest process to simulate. I will illustrate this purpose in the following(i use - as space):
-----------p2
-----------p1-----------p3---------p1----------t
-----------|------------|-----------|----------->(the - at this line are real -)
-----------t1-----------t2----------t3

@t1, when first executing p1, the next_process_time should be t1, at which p2 is schedules.
@t2, when executing p3, the next_process_time should be t3.

At the moment, it is not possible to get this info from kernel, because the API 'sc_curr_simcontext->next_time()' will return the notify time of the soonest timed event, hence ignoring the process scheduled at the current time(including the delta events).

I am afraid that I have to change the kernel to realize this purpose, which is not appreciated by the systemc community. But I am not able to see other possibility at the moment.

If you are trying to create a generic solution to instrument process activity for any design, then yes you might need to hack into the kernel. However if this is for a specific design you might consider adding this tracking out of the kernel, like setting flags on process re-entry and suspension and making flag setters for the other events that might trigger it. But its still not clear to me why you are trying to do this so its hard to comment.

Why are you trying to know the next process to simulate?

It is because I think i have an idea of avoiding some unnecessary 'wait()' in a thread:
by informing it about the concurrency undergone by the kernel.
Example goes like this:
thread1()
{...
-wait(10,SC_NS); //i will call 10 NS the delta_t
//if this thread knows that the next thread the kernel advances will happen later than
//now+10NS, then this thread could avoid this wait call, instead it accumulate this 10ns
//at its local timer: local_t. In this case, let's say there is no concurrency.
//Otherwise, it calls wait(local_t+delta_t), due to concurrency exists.
//So, now i can code it like this:
-if( exist_concurrency(local_t+delta_t) )
--wait(local_t + delta_t);
-else
--local_t+=delta_t;
...
}
Illustration goes like this:
----.----+-------+
----|----|--------|
----|----|--------|
----th1-v--------v----------p2
----|----|--------|-----------|----|-------->
----t1---t2-------t3----------t4---t5 (i should have used the embedded code for this part)
@t1, th1 wants to wait(t2-t1), but it is informed that the next process is at t4,
so th1 does not suspend and simulates on.
@t2, th1 wants to wait(t3-t2), same story.
@t3, th1 wants to wait(t5-t3), now th1 has to wait.

In short, wait() is for simulating concurrency, thus, if there is no concurrency, dont do wait().