Simplify wait in slices logic. NFC. #15739

kleisauke · 2021-12-10T13:16:15Z

Split from PR #13007.

sbc100 · 2021-12-10T15:14:53Z

system/lib/libc/musl/src/thread/pthread_barrier_wait.c

@@ -88,17 +88,16 @@ int pthread_barrier_wait(pthread_barrier_t *b)
 			a_spin();
 		a_inc(&inst->finished);
 #ifdef __EMSCRIPTEN__
-		int is_runtime_thread = emscripten_is_main_runtime_thread();
+		const int is_runtime_thread = emscripten_is_main_runtime_thread();


I think think this make any difference for basic types like int.

Ah yes, reverted with commit 4de581a.

sbc100 · 2021-12-10T15:16:15Z

system/lib/pthread/library_pthread.c

  // If we have less than this many msecs left to wait, busy spin that instead.
-  const double minimumTimeSliceToSleep = 0.1;
+  const double minTimeSliceToSleep = 0.1;


Lets use snake case since we are in C and drop the const. e.g. double min_time_slice_to_sleep. Lets make that into its own cleanup PR?

I'll split that into its own PR. Although, this file contains many camelCase variables. Maybe we should do that only for the code we touch in musl?

I think this camelCase exists here because it was ported from JS where we do use camelCase. How about doing a naming-only PR.. either before or after this one is fine with.

Naming-only PR sounds good to me.

sbc100 · 2021-12-10T15:17:54Z

system/lib/pthread/library_pthread.c

@@ -640,7 +634,7 @@ void emscripten_current_thread_process_queued_calls() {
  pthread_mutex_unlock(&call_queue_lock);

  // If the queue was full and we had waiters pending to get to put data to queue, wake them up.
-  emscripten_futex_wake((void*)&q->call_queue_head, 0x7FFFFFFF);
+  emscripten_futex_wake((void*)&q->call_queue_head, INT_MAX);


This can be part of the cleanup PR too.

Reverted with commit 1650785, I'll make a PR with these changes only.

sbc100 · 2021-12-10T15:19:13Z

system/lib/pthread/library_pthread.c

+    timeoutMSecs = timeoutUntilTime - emscripten_get_now();
+  } while (!done && timeoutMSecs > 0);
+
+  emscripten_set_current_thread_status(EM_THREAD_STATUS_RUNNING);


Is the something else going on here other than some re-ordering of the code?

Consolidation of the if-statements makes this diff difficult to read. Reverted with commit d78e59f for now.

sbc100 · 2021-12-10T15:19:29Z

system/lib/pthread/library_pthread.c

+
+  emscripten_set_current_thread_status(EM_THREAD_STATUS_RUNNING);
+
+  return done ? EMSCRIPTEN_RESULT_SUCCESS : EMSCRIPTEN_RESULT_TIMED_OUT;


This line can go in the cleanup PR too.

Reverted with commit d78e59f for now, I'll make a PR later with this change.

sbc100 · 2021-12-10T15:34:02Z

system/lib/libc/musl/src/thread/__timedwait.c

@@ -95,11 +94,13 @@ int __timedwait_cp(volatile int *addr, int val,
 	r = -__futex4_cp(addr, FUTEX_WAIT|priv, val, top);
 #endif
 	if (r != EINTR && r != ETIMEDOUT && r != ECANCELED) r = 0;
+#ifndef __EMSCRIPTEN__ // XXX Emscripten revert musl commit a63c0104e496f7ba78b64be3cd299b41e8cd427f


What is this change doing? Can/should it split into its own PR?

It was excluding code that is not related to Emscripten. Reverted with commit 6ea3ad3 for now.

sbc100 · 2021-12-10T15:34:59Z

system/lib/libc/musl/src/thread/__timedwait.c


 int __timedwait_cp(volatile int *addr, int val,
 	clockid_t clk, const struct timespec *at, int priv)
 {
 	int r;
 	struct timespec to, *top=0;

+#ifndef __EMSCRIPTEN__
 	if (priv) priv = FUTEX_PRIVATE;


Unnecessary code size optimization change, reverted with commit 6ea3ad3.

sbc100 · 2021-12-10T15:36:15Z

system/lib/libc/musl/src/thread/__timedwait.c

+	const int is_runtime_thread = emscripten_is_main_runtime_thread();
+
+	// Main runtime thread may need to run proxied calls, so sleep in very small slices to be responsive.
+	const double maxMsecsToSleep = is_runtime_thread ? 1 : 100;


Split out hoisting of self into a separate PR? (combine with use of self in
system/lib/libc/musl/src/thread/__wait.c)

Reverted with commit a9550ff. I'll make a new PR with this.

sbc100 · 2021-12-10T15:37:24Z

system/lib/libc/musl/src/thread/__wait.c

+	const int is_runtime_thread = emscripten_is_main_runtime_thread();
+
+	// Main runtime thread may need to run proxied calls, so sleep in very small slices to be responsive.
+	const double maxMsecsToSleep = is_runtime_thread ? 1 : 100;


Use snake_case in C code.

Commit 190b6b9 fixes this for the changed lines.

sbc100 · 2022-01-12T14:30:33Z

LGTM in general.

I have been thinking we can probable followup by removing a lot of this code... since emscripten_futex_wait itself already does time slicing on the main thread, I'm not sure its need at all in these places!

sbc100 · 2022-01-12T14:31:11Z

@juj, what do you think about this? If emscripten_futex_wait already does time slicing do you know why we are also doing it in all these higher level places?

kleisauke · 2022-01-12T14:51:04Z

I think it's still needed for cancellation points (i.e. for cases where the thread is cancelled in between). This is done in __timedwait_cp, __wait and emscripten_thread_sleep. We might experiment with calling emscripten_futex_wait directly in pthread_barrier_wait.

sbc100 · 2022-01-12T15:08:56Z

I think it's still needed for cancellation points (i.e. for cases where the thread is cancelled in between). This is done in __timedwait_cp, __wait and emscripten_thread_sleep. We might experiment with calling emscripten_futex_wait directly in pthread_barrier_wait.

What if we adding a cancellation point to the emscripten_futex_wait? Would that be a good idea anyway?

The alternative, would be to remove the time slicing from the emscripten_futex_wait loop. I tried that here but decided it would be probably be better to keep this one and drop the others: #15975

juj · 2022-01-13T10:02:59Z

system/lib/pthread/library_pthread.c

+      continue;
+
+    emscripten_futex_wait(&dummyZeroAddress, 0,
+      ms_to_sleep > max_ms_slice_to_sleep ? max_ms_slice_to_sleep : ms_to_sleep);


Here the code used to be of form

emscripten_futex_wait(..., ms_to_sleep);

but it gets refactored to form

emscripten_futex_wait(..., ms_to_sleep > max_ms_slice_to_sleep ? max_ms_slice_to_sleep : ms_to_sleep);

Above in file system/lib/libc/musl/src/thread/__wait.c the code used to be

emscripten_futex_wait(..., is_runtime_thread ? 1 : 100);

but it gets refactored to

emscripten_futex_wait(..., max_ms_to_sleep);

The PR looks to me like it is massaging the code back and forth, I am not sure if I see the guiding idea here. (sorry!)

Ah yes, it's a bit confusing. The difference between system/lib/libc/musl/src/thread/__wait.c and system/lib/pthread/library_pthread.c is that the former needs to wait indefinitely in slices, so it's doing this:

emscripten_futex_wait(..., max_ms_slice_to_sleep);

and the later must wait in slices for a certain time, so it does this:

emscripten_futex_wait(..., MAX(ms_to_sleep, max_ms_slice_to_sleep));

I've renamed the max_ms_to_sleep variable to max_ms_slice_to_sleep with commit 5b77bd9.

I'd rather avoid the ternary operation here. I think it makes the code easier to read if the calculation for how long to sleep is doing before the line where the sleep occurs. It also make it easier for debugging since you have a name for the actual amount of time that is we are going to sleep for.

Don't you find "ms_to_sleep > max_ms_slice_to_sleep ? max_ms_slice_to_sleep : ms_to_sleep" in addition to need to function call split over two lines harder to read?

You're right, those long variable names make it hard to read when being used within a ternary operator. Split over 2 lines with commit f84985c to improve readability.

juj · 2022-01-13T10:05:26Z

system/lib/libc/musl/src/thread/__timedwait.c

-		} while(r == ETIMEDOUT);
+
+			msecsToSleep = sleepUntilTime - emscripten_get_now();
+		} while (r == ETIMEDOUT && msecsToSleep > 0);


This change has the subtle difference that before, if one had a wait time of zero, then the wait loop would process emscripten_main_thread_process_queued_calls() and exit, but after this change, there is now an unconditional call out to emscripten_futex_wait(). It is uncertain what that will do, it could yield back the remaining time slice at minimum, or it could do a full kernel wait that gets triggered via the general timeout mechanism, so performance could theoretically be affected.

You're right, I avoided calls to emscripten_futex_wait() when msecsToSleep <= 0 with commit 54f145c and c4dfaf3.

juj

lgtm

juj · 2022-01-13T10:10:34Z

What if we adding a cancellation point to the emscripten_futex_wait?

I think it would be best not to have emscripten_futex_wait depend on the pthreads API. That was probably the guiding principle - the Emscripten API resides on a lower level that is not tied to POSIX pthreads itself.

kleisauke · 2022-01-15T10:45:42Z

Test failures in https://circleci.com/gh/emscripten-core/emscripten/492229 looks real, I could reproduce that sometimes locally. It seems that emscripten_main_thread_process_queued_calls() must always called before emscripten_futex_wait() in order to fix that (see commit 9477d68).

By always calling `emscripten_main_thread_process_queued_calls()` before `emscripten_futex_wait()`.

Improves readability.

kleisauke · 2022-01-20T12:35:52Z

Rebased to fix code size test failures in test_minimal_runtime_code_size_hello_webgl{,2}_wasm2js (commit f1fbd4c).

sbc100 · 2022-01-20T17:02:45Z

So is this change now completely non-functional? How sure are you that there are no observable changes?

Its not clear to me exactly what we gain from landing this PR? Is the idea just to make variable call sites be more consistent?
Or is there a codesize or readability improvement here?

I'm not against landing this if it really is NFC.

As it's essentially a bug fix.

kleisauke · 2022-01-20T17:31:30Z

So is this change now completely non-functional? How sure are you that there are no observable changes?

I think all changes are completely non-functional expect for the pthread_barrier_wait.c change (which unifies the emscripten_main_thread_process_queued_calls and emscripten_futex_wait call order). That change looks like a bug fix, as the commit prior to 40064d6 where causing test failures.

Its not clear to me exactly what we gain from landing this PR? Is the idea just to make variable call sites be more consistent?
Or is there a codesize or readability improvement here?

You're right, the current state of this PR is that there is not much to gain other than readability and consistency. The reason for this PR was mainly the now-reverted 21c0823 commit, which I'll open a PR for later.

I'm not against landing this if it really is NFC.

I completely understand that, I just reverted the pthread_barrier_wait.c change with commit ecbd5fa.

sbc100 · 2022-01-20T16:54:48Z

system/lib/pthread/library_pthread.c

-    }
-    now = emscripten_get_now();
-  };
+    emscripten_futex_wait(&dummyZeroAddress, 0, ms_to_sleep);


The loop condition here seems a little odd to me. It doesn't seem to take into account that time has elapsed during emscripten_futex_wait. Perhaps adding ms_to_sleep = target - now; as the very last thing line of the loop would fix it? But then we are kind of re-using the single ms_to_sleep to mean two different things: How long to sleep for this loop cylcle, and the total remain time to sleep.. Maybe we should keep those things logically separate for readability?

Commit 7d74c53 takes the elapsed time during emscripten_futex_wait into account.

kleisauke mentioned this pull request Dec 10, 2021

[WIP] Experiment with atomic builtins on Node #15740

Closed

sbc100 reviewed Dec 10, 2021

View reviewed changes

kleisauke force-pushed the simplify-wait-slices branch 3 times, most recently from fbdfa0c to 648a20e Compare January 12, 2022 13:59

juj reviewed Jan 13, 2022

View reviewed changes

juj approved these changes Jan 13, 2022

View reviewed changes

kleisauke force-pushed the simplify-wait-slices branch from c4dfaf3 to 9477d68 Compare January 15, 2022 10:44

kleisauke added 12 commits January 20, 2022 13:30

Simplify/unify wait in slices logic. NFC.

59aac0a

Revert unnecessary changes

c0b7882

Revert hoisting of self changes

21c0823

Revert small doc changes

e9692af

Drop const for changed lines

2a52598

Prefer snake_case for changed lines

4b8a024

Revert emscripten_wait_for_call_v change

961e320

Consolidate vars

4784dfa

s/max_ms_to_sleep/max_ms_slice_to_sleep/g

02ba5d6

Avoid call to emscripten_futex_wait when msecsToSleep <= 0

c8d47d0

Resolve test failures

40064d6

By always calling `emscripten_main_thread_process_queued_calls()` before `emscripten_futex_wait()`.

Split ternary operation over 2 lines

70bfc3b

Improves readability.

kleisauke force-pushed the simplify-wait-slices branch from f84985c to 70bfc3b Compare January 20, 2022 12:34

Revert non-NFC change

ecbd5fa

As it's essentially a bug fix.

kleisauke changed the title ~~Simplify/unify wait in slices logic. NFC.~~ Simplify wait in slices logic. NFC. Jan 20, 2022

sbc100 approved these changes Jan 20, 2022

View reviewed changes

Incorporate review comment

7d74c53

sbc100 enabled auto-merge (squash) January 20, 2022 19:47

sbc100 merged commit ba84d40 into emscripten-core:main Jan 20, 2022

kleisauke deleted the simplify-wait-slices branch January 29, 2022 10:44


		emscripten_set_current_thread_status(EM_THREAD_STATUS_RUNNING);

		return done ? EMSCRIPTEN_RESULT_SUCCESS : EMSCRIPTEN_RESULT_TIMED_OUT;

Simplify wait in slices logic. NFC. #15739

Simplify wait in slices logic. NFC. #15739

Uh oh!

Conversation

kleisauke commented Dec 10, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sbc100 commented Jan 12, 2022

Uh oh!

sbc100 commented Jan 12, 2022

Uh oh!

kleisauke commented Jan 12, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sbc100 commented Jan 12, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kleisauke Jan 13, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

juj left a comment

Choose a reason for hiding this comment

Uh oh!

juj commented Jan 13, 2022

Uh oh!

kleisauke commented Jan 15, 2022

Uh oh!

kleisauke commented Jan 20, 2022

Uh oh!

sbc100 commented Jan 20, 2022

Uh oh!

kleisauke commented Jan 12, 2022 •

edited

Loading

kleisauke Jan 13, 2022 •

edited

Loading