Project

General

Profile

Bug #2359

test_threads.rb:test_list

Added by docwhat (Christian Höltje) over 9 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Normal
Target version:
-
ruby -v:
ruby 1.9.1p243 (2009-07-16 revision 24175) [sparc-solaris2.8]
Backport:
[ruby-core:26694]

Description

=begin
In test/ruby/test_threads.rb:
test_list errors or hangs on Sparc64 Solaris.

I think the problem is that when using native threads, loop{} starves the other threads. I can "fix" running the internal eval'd code by changing the loop{} to be loop{puts 'fubar'}. But that only works if it sends to the terminal (the io causes the thread to let go). Since it's being captured by assert_in_out_err() that doesn't really work.

A work around is to change loop{} to loop{Thread.pass} but I don't know if this still tests what it is supposed to test.
=end


Related issues

Related to Ruby master - Bug #3890: ビジースレッドがあるとコンテキストスイッチが起きづらくなるClosedActions

Associated revisions

Revision 450463d5
Added by ko1 (Koichi Sasada) over 8 years ago

  • thread.c, vm_core.h: make gvl_acquire/release/init/destruct APIs to modularize GVL implementation.
  • thread_pthread.c, thread_pthread.h: Two GVL implementations. (1) Simple locking GVL which is same as existing GVL. (2) Wake-up queued threads. The wake-up order is simple FIFO. (We can make several queues to support exact priorities, however this causes some issues such as priority inversion and so on.) This impl. prevents spin-loop (*1) caused on SMP environemnts. *1: Only one Ruby thread acqures GVL again and again. Bug #2359 [ruby-core:26694]
  • thread_win32.c, thread_win32.h: Using simple lock not by CRITICAL_SECTION but by Mutex. Bug #3890 [ruby-dev:42315]
  • vm.c (ruby_vm_destruct): ditto.

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@29956 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

Revision 29956
Added by ko1 (Koichi Sasada) over 8 years ago

  • thread.c, vm_core.h: make gvl_acquire/release/init/destruct APIs to modularize GVL implementation.
  • thread_pthread.c, thread_pthread.h: Two GVL implementations. (1) Simple locking GVL which is same as existing GVL. (2) Wake-up queued threads. The wake-up order is simple FIFO. (We can make several queues to support exact priorities, however this causes some issues such as priority inversion and so on.) This impl. prevents spin-loop (*1) caused on SMP environemnts. *1: Only one Ruby thread acqures GVL again and again. Bug #2359 [ruby-core:26694]
  • thread_win32.c, thread_win32.h: Using simple lock not by CRITICAL_SECTION but by Mutex. Bug #3890 [ruby-dev:42315]
  • vm.c (ruby_vm_destruct): ditto.

Revision 29956
Added by ko1 (Koichi Sasada) over 8 years ago

  • thread.c, vm_core.h: make gvl_acquire/release/init/destruct APIs to modularize GVL implementation.
  • thread_pthread.c, thread_pthread.h: Two GVL implementations. (1) Simple locking GVL which is same as existing GVL. (2) Wake-up queued threads. The wake-up order is simple FIFO. (We can make several queues to support exact priorities, however this causes some issues such as priority inversion and so on.) This impl. prevents spin-loop (*1) caused on SMP environemnts. *1: Only one Ruby thread acqures GVL again and again. Bug #2359 [ruby-core:26694]
  • thread_win32.c, thread_win32.h: Using simple lock not by CRITICAL_SECTION but by Mutex. Bug #3890 [ruby-dev:42315]
  • vm.c (ruby_vm_destruct): ditto.

Revision 29956
Added by ko1 (Koichi Sasada) over 8 years ago

  • thread.c, vm_core.h: make gvl_acquire/release/init/destruct APIs to modularize GVL implementation.
  • thread_pthread.c, thread_pthread.h: Two GVL implementations. (1) Simple locking GVL which is same as existing GVL. (2) Wake-up queued threads. The wake-up order is simple FIFO. (We can make several queues to support exact priorities, however this causes some issues such as priority inversion and so on.) This impl. prevents spin-loop (*1) caused on SMP environemnts. *1: Only one Ruby thread acqures GVL again and again. Bug #2359 [ruby-core:26694]
  • thread_win32.c, thread_win32.h: Using simple lock not by CRITICAL_SECTION but by Mutex. Bug #3890 [ruby-dev:42315]
  • vm.c (ruby_vm_destruct): ditto.

Revision 29956
Added by ko1 (Koichi Sasada) over 8 years ago

  • thread.c, vm_core.h: make gvl_acquire/release/init/destruct APIs to modularize GVL implementation.
  • thread_pthread.c, thread_pthread.h: Two GVL implementations. (1) Simple locking GVL which is same as existing GVL. (2) Wake-up queued threads. The wake-up order is simple FIFO. (We can make several queues to support exact priorities, however this causes some issues such as priority inversion and so on.) This impl. prevents spin-loop (*1) caused on SMP environemnts. *1: Only one Ruby thread acqures GVL again and again. Bug #2359 [ruby-core:26694]
  • thread_win32.c, thread_win32.h: Using simple lock not by CRITICAL_SECTION but by Mutex. Bug #3890 [ruby-dev:42315]
  • vm.c (ruby_vm_destruct): ditto.

Revision 29956
Added by ko1 (Koichi Sasada) over 8 years ago

  • thread.c, vm_core.h: make gvl_acquire/release/init/destruct APIs to modularize GVL implementation.
  • thread_pthread.c, thread_pthread.h: Two GVL implementations. (1) Simple locking GVL which is same as existing GVL. (2) Wake-up queued threads. The wake-up order is simple FIFO. (We can make several queues to support exact priorities, however this causes some issues such as priority inversion and so on.) This impl. prevents spin-loop (*1) caused on SMP environemnts. *1: Only one Ruby thread acqures GVL again and again. Bug #2359 [ruby-core:26694]
  • thread_win32.c, thread_win32.h: Using simple lock not by CRITICAL_SECTION but by Mutex. Bug #3890 [ruby-dev:42315]
  • vm.c (ruby_vm_destruct): ditto.

Revision 29956
Added by ko1 (Koichi Sasada) over 8 years ago

  • thread.c, vm_core.h: make gvl_acquire/release/init/destruct APIs to modularize GVL implementation.
  • thread_pthread.c, thread_pthread.h: Two GVL implementations. (1) Simple locking GVL which is same as existing GVL. (2) Wake-up queued threads. The wake-up order is simple FIFO. (We can make several queues to support exact priorities, however this causes some issues such as priority inversion and so on.) This impl. prevents spin-loop (*1) caused on SMP environemnts. *1: Only one Ruby thread acqures GVL again and again. Bug #2359 [ruby-core:26694]
  • thread_win32.c, thread_win32.h: Using simple lock not by CRITICAL_SECTION but by Mutex. Bug #3890 [ruby-dev:42315]
  • vm.c (ruby_vm_destruct): ditto.

History

#1

Updated by docwhat (Christian Höltje) over 9 years ago

=begin
I forgot to add that this test works in Linux 32 and 64.
=end

#2

Updated by ujihisa (Tatsuhiro Ujihisa) over 9 years ago

  • Status changed from Open to Assigned
  • Assignee set to nobu (Nobuyoshi Nakada)

=begin

=end

#3

Updated by mame (Yusuke Endoh) about 9 years ago

  • Priority changed from Normal to 3

=begin
Hi,

Sorry for late reply. I had trouble setting up Sparc Solaris.
I managed to prepare it, but I found the test worked for me.

$ ./ruby test/ruby/test_thread.rb
Loaded suite test/ruby/test_thread
Started
................................
Finished in 16.655716 seconds.

32 tests, 85 assertions, 0 failures, 0 errors, 0 skips

Test run options: --seed 60800

$ file ruby
ruby: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped

$ uname -a
SunOS blade1000dev.home.yugui.jp 5.10 Generic_142900-03 sun4u sparc SUNW,Sun-Blade-1000

I guess there may be some race condition, but we can't debug
unreproducible issue. So the priority is set to Low.
Contribution (debugging the issue and writing a patch) is
wanted.

--
Yusuke Endoh mame@tsg.ne.jp
=end

#4

Updated by ko1 (Koichi Sasada) over 8 years ago

  • Status changed from Assigned to Closed
  • % Done changed from 0 to 100

=begin
This issue was solved with changeset r29956.
Christian, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

=end

Also available in: Atom PDF