On 12/15/00, Bill Pugh <pugh@cs.umd.edu> wrote:
> I misread something in your code. I now see your intent: to have two
> versions of the code: one for the Alpha, another for other platforms.
> A simpler way to write it would be:
>
> class Foo {
> private Helper helper = null;
> public Helper getHelper() {
> if (GlobalSettings.allowsDependentReadsToBeReordered || helper != null) {
> synchronized(this) {
> if (helper == null)
> helper = new Helper();
> }
> return helper;
> }
> }
>
> This still doesn't work on systems where
> GlobalSettings.allowsDependentReadsToBeReordered is false, unless you
> also prohibit reordering of writes (by either the compiler or
> processor). There are various ways to try to hack around it, but they
> are all ugly.
I think you may have overlooked another aspect of the intent. The purpose
of the "else" is to prevent the reordering of writes. If you simplify the
code by removing the "else," you lose the protection; the simplified code
above has the same reordered-write vulnerability that double-check has.
I don't think the idiom below suffers from that vulnerability; does it?
>>>> class Foo {
>>>> private Helper helper = null;
>>>> private boolean helperExists;
>>>> public Helper getHelper() {
>>>> if (!helperExists)
>>>> synchronized(this) {
>>>> if (helper == null)
>>>> helper = new Helper();
>>>> else
>>>> helperExists = GlobalSettings.ALLOW_UNSYNCHRONIZED_READ;
>>>> }
>>>> return helper;
>>>> }
>>>> // other functions and members...
>>>> }
> More importantly, if such flags were available, 99.999999% of all
> programmers who used them would use them incorrectly. I would like to
> avoid putting too many loaded guns into the revised spec.
Agreed; that's not what Java is about. I'm not asking about a new feature
for the next version of Java -- I'm asking about a way to allow people who
install this particular web server to squeeze more hits-per-second out of
their current JVM, yet still be able to move the server to any future JVM
just by changing the value of one Boolean parameter in a configuration file.
-- Robert Munyer <munyer@digi-net.com>
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:29 EDT