Data that is only ever accessed (read or modified) from a single context.This "something" is some kind of lock.Į) Some data does not need any lock.
For example, if one thread is modifying one thing, then you do not want all other threads to be unable to access/modify completely unrelated things.Ĭ) With something like "_AtomicEnter()", there's no way to know what data is involved, and therefore no way to ensure that different contexts are able to modify different pieces of data at the same time, and no way to get acceptable performance/scalability.ĭ) For acceptable performance/scalability, you need something that's associated with the data. There MUST be a way to do this, probabling doing a CLI, but from then on, my mind is just blank.Ī) The general idea is to ensure that different contexts (CPUs, threads, whatever) aren't able to access the same data in ways that conflict and may cause problems.ī) For acceptable performance/scalability, you also need to ensure that different contexts are able to modify different pieces of data at the same time (where there is no conflict). Returning to the Atomicity problem, how can I implement _AtomicEnter/Exit(), in x86 for example? I DON'T want to use spinlocks or semaphores, as I think they're too and unneeded. Simple exception message here isn't enough to know how torepair the damage made).Īs you can see, the atomicity here is only a prevention and/or optimization, but it's still an example. Its final act before the actual far jump. ContextSwitch() is responsible for disabling the atomicity as * ContextSwitch() is an ArchImplement-ish function which (obviously) changes Process *new = autoselect ? _runningProcess->next : PMGetProcess(pid) * If autoselect = true, ignore pid and continue the chain. Volatile void PMContextSwitch(Bool autoSelect, PID pid) To set user/kernel-space, virtual memory, registers and other things It must be able to changeĪll machine-specific stuff and process all hackish operations needed
0 kommentar(er)
