Hi Dmitry,

Dmitry Adamushko wrote:
> Hello Jan,
> well, take it with 2 huge grains of salt.. it's even not compile-tested :-)

Yeah, that might explain while already trying to parse it manually
failed: What is xnintr_sync_stat_references? :)

> I don't think I've got it really nicer than your first patch.. the only 
> additional point is that
> 'prev = xnstat_get_current()' reference is also tracked as reference 
> accounting becomes
> a part of the xnstat interface (not sure we do need it though).

Mind to elaborate on _why_ you think we need this, specifically if it
adds new atomic counters? I'm too lazy looking for the probably valid
reason on my own. Apropos atomic use counters: already considered all
memory barrier issues for your locking scheme?

> Well (#2), I have to say that the whole intr subsystem looks not that nice 
> (maybe partly due
> to being overloaded with xnstat details).. so I think, it'd require a closer 
> look.

Let's get it right first, then think about aesthetic or even concrete
optimisations again.

> Anyway, here is what I've got out of your patch so far.. the main issue is 
> whether we go this way
> or it just makes things even more uglier.

Again, correctness, race-avoidance worries me first right now.

> (a side effect : I transformed xnstat_* macroses into 'static inline' 
> function.. I guess, this way it's a bit nicer)

Uhh, be careful, I burned my fingers with similar things recently as
well. You have to make sure that all types are resolvable for _all_
includers of that header. Otherwise, I'm fine with cleanups like this.
But I think there was once a reason for #define.


PS: Please note my latest refactoring check-in to SVN, touching stat.h.

Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to