As you say, from the perspective of the program any scheduling interleaving is possible. The OS can substitute a new scheduling algorithm any time it likes. Otherwise we could know that the possible set of executions is much smaller than the set of all interleavings, and could write our concurrent code based upon that assumption. Then we'd be SOL when anyone tweaked the scheduler.
What do you think about the definitions I gave of the two terms?
BTW, I'm going to pick on you a bit. I don't like it when people oversimplify things in CS. I think it can be confusing to beginners (and, sometimes, non-beginners). I don't like when people say things like "the scheduler can do whatever it wants," "the OS scheduler can change any time," "the scheduler is non-deterministic," etc., because I know those things aren't true. They may help make a point, but it's also introducing a source of potential confusion.
I say this from the perspective of somebody who has actually done some work on OS schedulers. I mean, to me, the OS never substitutes a new scheduling algorithm any time it likes, though an OS hacker may actually change the algorithm. And, as you may know, kernel hackers take advantage of known limitatations in concurrency (i.e., concurrency that will never "actually happen").
I don't see how it confuses people. In CS, the important thing is to specify the contract between subsystems. To your program, a preemptive scheduler's contract is it will run your threads in any order it wants. The point is not whether it's truly random or pseudo random. The point is there is no guarantee of ordering. You better deal with it. You cannot rely on the threads running in certain order. That's non-deterministic. It's a basic notion in concurrency.
Note that I never said the scheduler is non-deterministic. It is the order of your threads' execution that's non-deterministic.
It confuses people because (a) it's not true and (b) it's beside the point.
There are lots of schedulers out there that have a different contract than the one you described ("run threads in any order"). For example, many real-time systems run threads in priority order - you only get preempted if a higher-priority thread wants to run.
I think we are getting off-track here. The non-deterministic nature is about concurrent programs, not about scheduler. Scheduler is just one source causing non-deterministic execution order of threads. There are other non-deterministic causing sources.
Imagine you spin off 10 threads waiting for network requests where one thread per client machine. It cannot be deterministically decided which thread will run first and which will run next. It depends on which client connects to which thread first. That's the non-deterministic nature of the program. Concurrency is the discipline to deal with that problem.
Right, but if you make assumptions about the scheduler, you are tied to that scheduler's implementation, which introduces a significant coupling between OS implementation and language runtime that doesn't win you much and commits you to an implementation that, honestly, can and will change over time.
You wouldn't want to make assumptions about the scheduler if you're programming for a desktop, smartphone, or server, but you have to if you're programming a lot of kinds of embedded systems.
I think your definitions are good, although thread-centric - to be really precise you have to talk a bit about 'steps' in the operational semantics of the program, but it's not helpful usually to do so.
