pklanka at gmail
Jul 2, 2009, 9:04 PM
Post #3 of 4
(276 views)
Permalink
|
|
Re: [Code-Crunchers] a simple race condition and how you'd solve it
[In reply to]
|
|
I may be seriously wrong here; But how about implementing a simple bool
cache as a check for cache result computation.
result = cache.select(input)
if result:
return result
resultcompute = cache.select(resultcompute)
if (resultcompute == true) {
while(!cache.select(resultcompute)) {
}
return cache.select(result)
}
if resultcompute = null {
cache.insert(resultcompute, true)
result = compute(input)
cache.insert(input, result)
cache.insert(resultcompute, false)
}
return result
I think above code would work enough. I does not remove racy condition in
totality though. E.g. For a condition if two threads are accessing boolean
cache variable at the same time. But since boolean computation and inserting
into cache is a millisecond effort, this probability of two threads coming
at this point at same time is very much reduced.
regards
Phani
On Fri, Jul 3, 2009 at 7:34 AM, <Valdis.Kletnieks[at]vt.edu> wrote:
> On Fri, 03 Jul 2009 11:01:34 +1000, silky said:
>
> > Basically, you just need to check if you should still be computing,
> > and, at the end of computation, if your data is still "wanted".
>
> All that does is push the race condition around. You *still* need to
> do some sort of locking around the tail end. This is still racy:
>
> if (update_still_wanted) {
> stash_my_update();
> update_still_wanted = false;
> }
>
> (Admittedly, not *as* racy, especially if you move the assignment first.
> But
> that's still racy enough to actually *trip* on occasion - this sort of bug
> is actually found at least once a month in the Linux kernel in some device
> driver or other...)
>
> And to be honest - the "best" way of fixing this is *really* going to
> depend on
> the relative weight of locking (which can be *very* different if you have 2
> threads on 2 CPUs, or 4096 threads on a 4096-core monster, or are split
> across
> systems possibly in different countries connected by a high or maybe low
> speed
> network), and how much effort goes into the computation, and how much
> correctness matters - for some cases, you *really* want "first to finish"
> (possibly due to side effects of the computation), others "any complete
> answer"
> is good enough, etc..
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
|
