=begin

On Dec 22, 2008, at 11:10 AM, Charles Nutter wrote:

• When the autoload marker is encountered, it is replaced (under
  lock) with an "autoload in progress" marker. All subsequent threads
  will then see this marker and wait for the autoloading process to
  complete. the mechanics of this are a little tricky, but it would
  guarantee concurrent autoloads would only load the target file once
  and would always return the intended value to concurrent readers.
• A single autoload mutex, forcing all autoloads to happen in serial.

There is a potential for deadlock in the first solution,
unfortunately, since two threads autoloading two constants with
circular autoloaded constant dependencies would ultimately deadlock,
each waiting for the other to complete. Because of this, a single
autoload mutex for all autoloads may be the only safe solution.

Why not use the same lock that's used by require? The two are clearly
related, and if there's a require in progress, you'd want to suspend
autoload until it has finished, and the result of the require might
affect the behavior of the autoload.

Dave

=end

=begin
Dave Thomas wrote:

Why not use the same lock that's used by require? The two are clearly
related, and if there's a require in progress, you'd want to suspend
autoload until it has finished, and the result of the require might
affect the behavior of the autoload.

It probably could use the same lock; the trickier bit is that in between
encountering the autoload and requiring the file there's already state
changes happening. So I think we still need to ensure the autoload
marker is mutated under lock as well.

To be honest, I'm not sure autoload is really even possible to make safe
in the presence of threads...the design of it may be inherently
incompatible. But I'm willing to talk through some possibilities and see
what we can come up with.

=end

=begin

On Dec 22, 2008, at 1:44 PM, Charles Oliver Nutter wrote:

It probably could use the same lock; the trickier bit is that in
between encountering the autoload and requiring the file there's
already state changes happening. So I think we still need to ensure
the autoload marker is mutated under lock as well.

To be honest, I'm not sure autoload is really even possible to make
safe in the presence of threads...the design of it may be inherently
incompatible. But I'm willing to talk through some possibilities and
see what we can come up with.

Yeah--you'd need to make require transactional somehow.

Stupid question: does anyone actually use autoload?

Dave

=end

=begin
On Dec 23, 2008, at 05:53 AM, Dave Thomas wrote:

On Dec 22, 2008, at 1:44 PM, Charles Oliver Nutter wrote:

It probably could use the same lock; the trickier bit is that in
between encountering the autoload and requiring the file there's
already state changes happening. So I think we still need to ensure
the autoload marker is mutated under lock as well.

To be honest, I'm not sure autoload is really even possible to make
safe in the presence of threads...the design of it may be
inherently incompatible. But I'm willing to talk through some
possibilities and see what we can come up with.

Yeah--you'd need to make require transactional somehow.

Stupid question: does anyone actually use autoload?

RubyGems now does, but the code wasn't introduced by me.

=end

=begin

Currently autoload is not safe to use in a multi-threaded application.

My preference would be for it at most one thread to be "in an
autoload" at a time, so similar to require, no chance for confusion.
But then again that's just me :)

-r-

=end

=begin
On Tue, Dec 23, 2008 at 3:51 PM, Christian Neukirchen
chneukirchen@gmail.com wrote:

Dave Thomas dave@pragprog.com writes:

On Dec 22, 2008, at 1:44 PM, Charles Oliver Nutter wrote:

It probably could use the same lock; the trickier bit is that in
between encountering the autoload and requiring the file there's
already state changes happening. So I think we still need to ensure
the autoload marker is mutated under lock as well.

To be honest, I'm not sure autoload is really even possible to make
safe in the presence of threads...the design of it may be inherently
incompatible. But I'm willing to talk through some possibilities and
see what we can come up with.

Yeah--you'd need to make require transactional somehow.

Stupid question: does anyone actually use autoload?

Rack does. Merb does as well.

So does RbGCCXML, a random library that I'm using (I see no point as
to why it's doing so, to be honest).

-austin¶

Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
* austin@halostatue.ca * http://www.halostatue.ca/feed/
* austin@zieglers.ca

=end

=begin
Dave Thomas wrote:

To be honest, I'm not sure autoload is really even possible to make
safe in the presence of threads...the design of it may be inherently
incompatible. But I'm willing to talk through some possibilities and
see what we can come up with.

Yeah--you'd need to make require transactional somehow.

Yeah, that's essentially it (though it's more specific to autoload).
You'd need to lock the constant under autoload in such a way that other
threads would block until autoloading completed. And unless it were a
single global lock for all autoload logic, there's a strong potential
for deadlock if two threads encounter opposing constants at the same time.

Stupid question: does anyone actually use autoload?

They do, but they probably shouldn't. It's broken.

=end

=begin

On Dec 23, 2008, at 4:16 PM, Charles Oliver Nutter wrote:

Yeah--you'd need to make require transactional somehow.

Yeah, that's essentially it (though it's more specific to autoload).
You'd need to lock the constant under autoload in such a way that
other threads would block until autoloading completed. And unless it
were a single global lock for all autoload logic, there's a strong
potential for deadlock if two threads encounter opposing constants
at the same time.

Would it be sufficient to add field to each constant to say "loading
in progress in thread n"

Have the lock we've been talking about in autoload and require.

During require, set the current thread id into every newly defined
constant, keeping a list of the ones that are set. Maintain a stack of
the current requires. (These will all be in the same thread because of
the mutex).

When the last require finishes, go though all constants in the list
and unset the thread id in them. Finally, signal a condition variable.

Constant lookup then works like this: If the constant isn't defined,
claim the require mutex and then check for autoloading stuff.

If the constant is defined, check to see if the thread id is set in
the constant. If it is, wait on the condition variable. That way, you
won't pick up partially initialized constants that are being
autoloaded or required by other threads.

And, I know, this sounds ridiculously complex. But the only
alternative I see is locking the entire interpreter during requires.

Dave

=end

=begin
Hi,

At Tue, 23 Dec 2008 02:10:34 +0900,
Charles Nutter wrote in [ruby-core:20797]:

The current logic for autoload is as follows:

This description is old. Already autoload sees the same lock
used by require, as Dave Thomas mentioned in [ruby-core:20801].

So I guess the autoload specific issue has gone, and we could
focus on the issue of recursive/circular require, i.e.,
[ruby-core:20794].

--
Nobu Nakada

=end

=begin
Nobuyoshi Nakada wrote:

Hi,

At Tue, 23 Dec 2008 02:10:34 +0900,
Charles Nutter wrote in [ruby-core:20797]:

The current logic for autoload is as follows:

This description is old. Already autoload sees the same lock
used by require, as Dave Thomas mentioned in [ruby-core:20801].

So I guess the autoload specific issue has gone, and we could
focus on the issue of recursive/circular require, i.e.,
[ruby-core:20794].

So if two threads lookup the same autoload constant at the same time, is
the second thread guaranteed to wait until the first thread has finished
requiring?

I was not aware this had been fixed or decided.

=end

=begin
Hi,

At Wed, 24 Dec 2008 14:56:37 +0900,
Charles Oliver Nutter wrote in [ruby-core:20853]:

So I guess the autoload specific issue has gone, and we could
focus on the issue of recursive/circular require, i.e.,
[ruby-core:20794].

So if two threads lookup the same autoload constant at the same time, is
the second thread guaranteed to wait until the first thread has finished
requiring?

It's same as two threads requiring without autoloading.

--
Nobu Nakada

=end

=begin
Nobuyoshi Nakada wrote:

It's same as two threads requiring without autoloading.

I'm not sure this is safe enough. If the first thread has already set
the constant, the second thread would not know it is an autoload and
would return its value immediately. The resource the constant points at
may not be done loading.

my_file.rb:

module XXX
class Foo
# HERE
def bar; ... end
end
end

my_autoload.rb:

module XXX
autoload :Foo, "my_file.rb"
end

Thread 1¶

Thread.new { XXX::Foo.new.bar }

Thread 2¶

Thread.new { XXX::Foo.new.bar }

Thread 1 tries to look up XXX::Foo and starts requiring my_file.rb. It
reaches # HERE above and the XXX::Foo constant now points at the Foo
class. Now thread 2 looks up XXX::Foo, and since it is not an autoload
marker it gets the incomplete Foo class. Thread 2 blows up when it tries
to call bar because bar is not yet defined.

=end

=begin
At 10:53 PM +0900 12/23/08, Dave Thomas wrote:

Stupid question: does anyone actually use autoload?

Since the 2.2.2 release the rails trunk codebase has been doing a mass replacement of require with autoload.
=end

Sorry for commenting this dated ticket.

Charles: I agree with Nobu that it's not autoload specific issue but a thereaded require issue.

my_file.rb:

module XXX
class Foo
# HERE
def bar; ... end
end
end

my_load.rb:

Thread 1¶

Thread.new { require 'my_file'; XXX::Foo.new.bar }

Thread 2¶

Thread.new { XXX::Foo.new.bar }

Thread 2 can get NoMethodError(for bar) instead of NameError(for XXX) I think and it's Ruby's behavior at this moment.

I'm just commenting this for closing similar ticket of JRuby: http://jira.codehaus.org/browse/JRUBY-3194. Sorry for the noise.

The concurrent require issue is separate. I would like to understand what 1.9.3 does to make concurrent requires safe. A global lock around any require? I know there was a lock against specific filenames added at some point (which JRuby also does)...is there something more?

I do not understand how the autoload problem was fixed. Here is a simpler example...

autoload.rb:

class Object
autoload :X, 'constant.rb'
end

Thread.abort_on_exception = true

Thread.new {
puts "thread #{Thread.current} accessing X; defined? X == #{(defined? X).inspect}"
X
}
Thread.new {
puts "thread #{Thread.current} accessing X; defined? X == #{(defined? X).inspect}"
X
}
sleep

constant.rb:

simulate a slow file load or a deep chain of requires¶

puts "thread #{Thread.current} in constant.rb"

check that X is not defined¶

puts "X defined: #{(defined? X).inspect}"

1_000_000.times { Thread.pass }

class Object

define X¶

X = 1
end

I will review the problem.

When autoloading is triggered, the first step is to remove the autoload constant. This allows the file being required to see a blank slate when (presumably) defining the constant attached to autoloading. The above example does indeed print out "X defined: nil".

Now if we have two threads that encounter an autoloaded constant at roughly the same time, I would expect this sequence is possible:

For our autoloaded constant X:

1. Thread A encounters the autoload for X and removes the constant. It proceeds to require the associated file which (eventually) will define X.
2. Because thread A is now in Ruby code, a context switch can occur to thread B.
3. Thread B attempts to access the autoloaded constant X; however it has been removed by A, and thread B gets a NameError. It does not wait for the require to complete, because it never attempts to perform a require.

This is what happens in JRuby, Rubinius, and Ruby 1.8.7. It does not happen in Ruby 1.9.2 or MacRuby. Why?

Here is the output under 1.8.7:

~/projects/jruby ➔ ruby autoload.rb
thread #Thread:0x100169dc8 accessing X; defined? X == "constant"
thread #Thread:0x100169dc8 in constant.rb
X defined: nil
thread #Thread:0x100169080 accessing X; defined? X == nil
autoload.rb:13: uninitialized constant X (NameError)
from autoload.rb:11:in initialize' from autoload.rb:11:in new'
from autoload.rb:11

What appears to happen is that thread B encounters the X autoload and pauses. This could be explained for concurrent requires of the same file (if synchronizing against a filename), or for concurrent requires of different files (if there's a single global lock) but that still does not explain why autoload behaves this way in 1.9.2. Why? Because if thread A is actually removing the constant, it should never know that it's an autoload constant and should fail to block on a require lock of any kind. And it does appear that the constant has been removed...so how does thread B know to pause?

I could dig through the MRI code to find this, but perhaps can someone describe in simple terms how 1.9.2 prevents thread B in the example above from running when it encounters X?

Thanks. I've understand the issue is separated. The problem is not for method definition bar as you wrote in the previous example but for constant definition.

Anyway it looks fixed for CRuby, I'll back to http://jira.codehaus.org/browse/JRUBY-3194. The patch posted to JRUBY-3194 still doesn't solve the problem. Sigh.

FYI: shyouhei is working for the fix. Here's commits for ruby_1_8 branch.
http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?revision=31732&view=revision
http://svn.ruby-lang.org/cgi-bin/viewvc.cgi?revision=31734&view=revision
And a little modification for ruby_1_8_7 adjustment by me.
https://gist.github.com/992380

This patch intends;

• do not remove an autoload constant before autoloading.
• additional stop condition for edge case; when autoloading does not define the constant.

As I wrote above, this fix changes the following behavior.

% ruby187 -I. -e 'autoload(:X, "X"); begin; X; rescue LoadError; end; p Object.constants.include?("X")'
false #=> true like 1.9

Ruby developers, please let us know if you have any thoughts on this change.
With JRuby dev hat, I think it's OK. How other Ruby impls devs think?

I created a patch: https://github.com/nahi/ruby/compare/48bc63fa...54327abc
Here's the branch: https://github.com/nahi/ruby/commits/autoload-threadsafe

• let Module keep 'UNDEF' in constant map until the end of autoloading
• let Module keep actual object in another map (autoloading map)
• add extra checks for constant looku

Updated the patch: https://github.com/nahi/ruby/compare/11667b9c...8b78a18e
Rewritten with strust instead of st_table.

=begin

Here's the updated patch: [https://github.com/nahi/ruby/compare/11667b9c...03ddf439]

Summary

• ((What's the problem?)) autoload is thread unsafe. When we define a constant to be autoloaded, we expect the constant construction is invariant. But current autoload implementation allows other threads to access the constant while the first thread is loading a file. See http://prezi.com/ff9yptxhohjz/making-autoload-thread-safe/ for an example.

• ((What's happening inside?)) The current implementation uses Qundef as a marker of autoload in Constant table. Once the first thread find Qundef as a value at constant lookup, it starts loading a defined feature. Generally a loaded file overrides the Qundef in Constant table by module/class declaration at very beginning lines of the file, so other threads can see the new Module/Class object before feature loading is finished. It breaks invariant construction.

• ((How to solve?)) To ensure invariant constant construction, we need to override Qundef with defined Object after the feature loading. For keeping Qundef in Constant table, I expanded autoload_data struct in Module to have a slot for keeping the defined object while feature loading. And changed Module's constant lookup/update logic a little so that the slot is only visible from the thread which invokes feature loading. (== the first thread which accessed the autoload constant)

• ((Evaluation?)) All test passes (bootstrap test, test-all and RubySpec) and added 8 tests for threading behavior. Extra logics are executed only when Qundef is found, so no perf drop should happen except autoloading.

I'll commit this soon. Committers, please evaluate this.
=end

Hiroshi Nakamura nakahiro@gmail.com wrote:

I'll commit this soon. Committers, please evaluate this.

I noticed this got committed (r33078) and reverted (r33093).
Is a better commit planned? Thanks for working on this!

Hmm. Updating via reply e-mail seems to remove 'ruby -v'...

I re-apply r33078 and additional fixes at r33147. I tested it against Rails 3.1.0 and confirmed that it passes all of full tests except PG/MySQL/SQLite things which I don't installed properly.

Please evaluate it!

P.S. It won't included in 1.9.3 GA, but tell me if you find autoload threading issues on 193 as well, since RubyGems, RDoc, etc starts using autoload from 193. I think there's a chance to backport it. :)

Hiroshi Nakamura nakahiro@gmail.com wrote:

I re-apply r33078 and additional fixes at r33147. I tested it against
Rails 3.1.0 and confirmed that it passes all of full tests except
PG/MySQL/SQLite things which I don't installed properly.

Please evaluate it!

I got the following with r33147 on gcc (Debian 4.6.1-4) 4.6.1:

../variable.c: In function ‘autoload_defined_p’:
../variable.c:1613:5: error: implicit declaration of function ‘rb_autoloading_value’ [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors

Moving the definition of autoload_defined_p() after the definition of
rb_autoloading_value() trivially fixes my build:

--- a/variable.c
+++ b/variable.c
@@ -1601,18 +1601,6 @@ check_autoload_required(VALUE mod, ID id, const char **loadingpath)
return 0;
}

-static int
-autoload_defined_p(VALUE mod, ID id)
-{

• struct st_table *tbl = RCLASS_CONST_TBL(mod);
• st_data_t val;
• if (!tbl || !st_lookup(tbl, (st_data_t)id, &val) || ((rb_const_entry_t*)val)->value != Qundef) {
• return 0;
• }
• return !rb_autoloading_value(mod, id, NULL);
  -}

int
rb_autoloading_value(VALUE mod, ID id, VALUE* value)
{
@@ -1633,6 +1621,18 @@ rb_autoloading_value(VALUE mod, ID id, VALUE* value)
return 0;
}

+static int
+autoload_defined_p(VALUE mod, ID id)
+{

• struct st_table *tbl = RCLASS_CONST_TBL(mod);
• st_data_t val;
• if (!tbl || !st_lookup(tbl, (st_data_t)id, &val) || ((rb_const_entry_t*)val)->value != Qundef) {
• return 0;
• }
• return !rb_autoloading_value(mod, id, NULL);
  +}

struct autoload_const_set_args {
VALUE mod;
ID id;

Eric Wong

Eric Wong wrote:

I got the following with r33147 on gcc (Debian 4.6.1-4) 4.6.1:

../variable.c: In function ‘autoload_defined_p’:
../variable.c:1613:5: error: implicit declaration of function ‘rb_autoloading_value’ [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors

Moving the definition of autoload_defined_p() after the definition of
rb_autoloading_value() trivially fixes my build:
[snip]

NARUSE-san applied this at r33151. Thank, guys!

Apologies in advance if this is the wrong place to get clarification:

It's been widely circulated that autoload is deprecated - http://www.ruby-forum.com/topic/3036681 - does this patch change that stance?

I ask because autoload still appears to be the best route for libraries to avoid heavy load times; especially now that it is thread safe in JRuby and MRI.