<div dir="ltr"><div>Yeah, just realized that and sent my email pretty much literally a second after your email :)</div><div><br></div><div>Anyway, while yes in theory 1M threads are contending for the semaphore, but I don't think that should be a problem, because the contention is rather theoretical, since those "contending" VTs are just sitting in a queue, and after each release only one of them should be released. Also, I think Liam's comparison is fair, because none of the other two methods push back, so pushing back only in the VT version would be very unfair.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">robert engels <<a href="mailto:rengels@ix.netcom.com">rengels@ix.netcom.com</a>> ezt írta (időpont: 2024. máj. 30., Cs, 0:58):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">I remember that too, but in this case I don’t think it is the cause.<div><br></div><div>In the bounded/pooled thread scenario - you are only scheduling 600 threads (either platform or virtual).</div><div><div><br></div><div>In “scenario #2” all 1M virtual threads are created and are contending on a sempahore. This contention on a single resource does not occur in the other scenarios - this will lead to thrashing of the scheduler.</div><div><br></div><div>I suspect if it is run under a profiler it will be obvious. With 128 carrier threads, you have increased the contention over a typical machine by an order of magnitude.<br><div><br></div></div></div></div></blockquote></div></div>