full-disclosure - Re: [Code-Crunchers] a simple race condition and how you'd solve it

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Wed, 08 Jul 2009 14:35:49 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Valdis.Kletnieks@...edu
Cc: full-disclosure@...ts.grok.org.uk, fuzzing@...testar.linuxbox.org,
	code-crunchers@...testar.linuxbox.org, Gadi Evron <ge@...uxbox.org>
Subject: Re: [Code-Crunchers] a simple race condition and
	how you'd solve it

* Valdis Kletnieks:

> 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

Right.  And in general, it doesn't make sense to reinvent the wheel.
The platform probably has got some sort of ivar or future which takes
care of the synchronization/blocking.  (If it doesn't, you should
implement that abstraction first.)  Unless the computation is very,
very cheap (or requests are truly random), you want other threads to
block until the result computed in the initial thread becomes
available---without busy waiting.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/