KMLM List

[Alan Fitch <alan.fitch@xxxxxxxxxx>]

Andrea Pieretti wrote:
> I'm trying to implement my own channel and i wonder how can i avoid race
> condition.
> Suppose that i must use this channel to write the value of a shared
> resource.
> 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)

Hi Andrea,
  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
processing sequentially.

regards
Alan


-- 
Alan Fitch
http://www.doulos.com