Green Thread Experiment

[davidwrighton]

The CoreCLR team is experimenting with using green threads to support customers who are interesting in writing code in a synchronous style, but with the ability to suspend to a fairly small memory footprint when an asynchronous operation occurs. Green threads are

• Add a new Task api which creates code which executes in a mode where a thread can explicitly yield
  • Implement underlying technology for threads which can be suspended
    • [Green Threads] ThreadStatics are not integrated #2012
    • [Green Threads] Unique managed thread objects/ids are not implemented #2014
    • [Green Threads] GC tracking in suspended threads is not enabled. If a GC occurs, there will be heap corruption #2011
    • [Green Threads] FCalls do not swap to the OS stack #2017
    • [Green Threads] Various helper calls do not transition to the OS thread #2051
    • [Green Threads] PInvokes do not swap to the OS stack #2018,
    • [Green Threads] JIT does not generate the new prolog #2015
    • [Green Threads] - GC stackwalking with multiple stack segments #2010
  • Implement customer useable api surface
    • Flow the execution context into a green thread #2054
    • [Green Threads] - Integration into Task.Wait is probably wrong in various ways. #2016
    • [Green Threads] PInvokes to non-green-thread safe apis do not trigger thread pinning, and so can result in incorrect behavior #2013
    • Effectively a new Task api. Suspension will be implemented via Task.Wait()
  • Evaluate feasibility of productizing implementation
• Build ASP.NET api surface that uses green threading
  • Build ASP.NET using a runtimelab based build
  • Add new ASP.NET api surface
• Evaluate performance
  • Build benchmarks for core functionality
  • Build benchmarks for ASP.NET based functionality
  • Identify bottlenecks, and if they are fundamental, or merely implementation related

Experimental report published in #2398

[benaadams]

Assume it could also have potential address this issue by @krwq Proposition: Stack bending?

[davidwrighton]

@benadams, the current experiment as envisioned would allow for arbitrary stack growth (without any need for a magic function to all), but it's not at all clear that would be a practical approach in the long term to actually implement and make reliable. Very deep stacks introduce new, and interesting problems. My suspicion is that we'll actually need to have a constrained stack depth limit.

[ForkBug]

@davidwrighton Hi David, is Green-Threads feature still active, or dead?
If active, how to handle the following scenario?

A coroutine c1 wants to write a disk and then update a UI button.
A thread t1 schedules this coroutine until the coroutine starts writing to disk.
According to @davidfowl 's Twitter, the writing operation is async.
That means c1 will release the thread t1.
t1 will schedule another coroutine c2. c2 may need 10 seconds to finish.

But after a half second, c1 has finished the disk writing and wants to get an execution.

What will Green-Threads do?

1. Wait for the thread t1. This strategy will downgrade throughput. c1 have to wait for 9.5 seconds
2. Another thread t2 will schedule c1. If t1 is the UI thread, the following operation -- updates a UI button -- will fail, due to t2 is not the UI thread.

The problem is, OS will set some resources, or restrictions(like UI, tls, mutex, etc.), at thread level.

How does Green-Threads handle this problem?

[NCLnclNCL]

@davidwrightonXin chào David, tính năng Green-Threads vẫn hoạt động hay đã ngừng hoạt động? Nếu đang hoạt động thì xử lý tình huống sau như thế nào?

Một coroutine c1 muốn ghi đĩa rồi cập nhật nút giao diện người dùng. Một luồng t1 lên lịch cho coroutine này cho đến khi coroutine bắt đầu ghi vào đĩa. Dựa theo@davidfowlcủa Twitter, thao tác viết không đồng bộ. Điều đó có nghĩa là c1 sẽ giải phóng luồng t1. t1 sẽ lên lịch cho một coroutine c2 khác. c2 có thể cần 10 giây để hoàn thành.

Nhưng sau nửa giây, c1 đã ghi xong đĩa và muốn thực thi.

Chủ Đề Xanh sẽ làm gì?

1. Đợi chủ đề t1. Chiến lược này sẽ hạ thấp thông lượng. c1 phải đợi 9,5 giây
2. Một luồng khác t2 sẽ lên lịch c1. Nếu t1 là luồng giao diện người dùng, thao tác sau -- cập nhật nút giao diện người dùng -- sẽ thất bại, do t2 không phải là luồng giao diện người dùng.

Vấn đề là, HĐH sẽ đặt một số tài nguyên hoặc hạn chế (như UI, tls, mutex, v.v.) ở cấp luồng.

Green-Threads xử lý vấn đề này như thế nào?

Wait

[davidwrighton]

Experiment report has been published in #2398