Our forums have moved! Please go to http://forums.accellera.org for the new forums. The forums you see here will remain open for browsing, but are no longer open to new posts.
View email archives for the history of this mailing list.
systemc-forum - Re: [systemc-forum] Avoid Race Condition
- To: Andrea Pieretti <aenima1891@xxxxxxxxx>
- From: Alan Fitch <alan.fitch@xxxxxxxxxx>
- Date: Mon, 29 Jun 2009 16:40:28 +0100
- Cc: systemc-forum@xxxxxxxxxxxxxxxxx
- Send Email to email@example.com:
- Send new message
- Reply to this message
Andrea Pieretti wrote:|
> I'm trying to implement my own channel and i wonder how can i avoid race
> Suppose that i must use this channel to write the value of a shared
> I've tryied to use an sc_mutex but this lead to discrepancies...
> for examples if process1 obtain the lock, end then process2 and process3
> trying to obtain the lock in this order,
> then, when process1 frees the resource, the control pass to process3 and
> not to process2.
> It doesn't work like a fifo, but like a lifo (least in first out)
> is there a solution to this problem?
> thanks to anyone who will help me
> (and sorry for my bad english)
the simple answer is "don't use a shared resource" :-)
The sc_mutex channel is defined by the LRM. Any processes are resumed in
an indeterminate order - you can't assume anything (it might not be LIFO
on another implementation of SystemC).
You might want to have a look at the source code of the sc_fifo class to
see how that copes with simultaneous read/write in the same delta.
You can also explicitly synchronise processes to some sequence of events
to guarantee avoiding races - for instance create a series of sc_events
that notify in consecutive times (or deltas) then trigger each stage of