There are some instructions back from SSE3, MONITOR and

MWAIT, could it be in a way usefull for a programmer? *

* apart of other interesting commands for cache hints and branch

prediction hints - is some skilled asembly man able to do a good

usage from this type kind of comands here ?(this is the 2cond

question but first is specific about MONITOR and MWAIT)

(i know it is deep system architecture dabbling but sometimes i am

interested in this kind of things)

Short answer: Yes.

Long answer: No.

Wait... the long answer is shorter than the short answer... so here comes the explanation. First, a processor is not required to honor MWAIT at all, which is more like a hint. What the processor actually does is "implementation defined", which can be pretty much anything. That means that it isn't very reliable for the most tempting use case.

But more importantly, it is possible for the operating system to disable the instruction, and this is demonstrably done by major operating systems such as e.g. Windows. You will get an illegal instruction exception when trying to use the instruction. Insofar it is only "useful" for crashing your program.

I would assume that the probable reason for disabling the instruction would be that it interferes with scheduling. Assuming you issue a MWAIT and the processor goes into its implementation-defined sleep state, it might take much longer than anticipated to come back when a timer or other interrupt fires (I don't know if that is really the reason, but I would think so).

well for me at least MONITOR seem to be very interesting feature of the cpu ... MWAIT maybe less

What would you do with MONITOR if you can't use MWAIT?

You can set up some memory addresses that will wake up the CPU that is sleeping in MWAIT when the memory is being written to. Great, except you aren't allowed to use MWAIT because the OS disables it. Insofar MONITOR alone is pretty useless, isn't it?

MONITOR/MWAIT sounds very tempting as an event-like synchronization primitive (in fact, it could very easily implement a semaphore or any other sync primitive as well) supported directly in hardware with no need for OS support, no complicated logic, or the overhead of a syscall. Which sounds just great. Except... it doesn't work.

And then, as mentioned, there's that beast called "implementation specified" coming with it. Which basically means that even assuming it "works" (i.e. not disabled by OS) you still cannot rely 100% that it will really work as expected. The CPU might not go to sleep until woken but might continue execution, this is explicitly allowed. And lastly, of course, there's tons of other events such as TLB invalidation or CR modifications or faults that will also cause MWAIT to wake up, even when you didn't ask for it.

So you have to add a spinning wrapper around it to ensure correctness. Which basically means you end up writing the same code as for a normal spinlock, only with MWAIT in the middle instead of PAUSE, plus extra checks to account for spurious wakeups... which makes it kind of "bleh".

What would you do with MONITOR if you can't use MWAIT?

You can set up some memory addresses that will wake up the CPU that is sleeping in MWAIT when the memory is being written to. Great, except you aren't allowed to use MWAIT because the OS disables it. Insofar MONITOR alone is pretty useless, isn't it?

MONITOR/MWAIT sounds very tempting as an event-like synchronization primitive (in fact, it could very easily implement a semaphore or any other sync primitive as well) supported directly in hardware with no need for OS support, no complicated logic, or the overhead of a syscall. Which sounds just great. Except... it doesn't work.

And then, as mentioned, there's that beast called "implementation specified" coming with it. Which basically means that even assuming it "works" (i.e. not disabled by OS) you still cannot rely 100% that it will really work as expected. The CPU might not go to sleep until woken but might continue execution, this is explicitly allowed. And lastly, of course, there's tons of other events such as TLB invalidation or CR modifications or faults that will also cause MWAIT to wake up, even when you didn't ask for it.

So you have to add a spinning wrapper around it to ensure correctness. Which basically means you end up writing the same code as for a normal spinlock, only with MWAIT in the middle instead of PAUSE, plus extra checks to account for spurious wakeups... which makes it kind of "bleh".

ye maybe... its hardto belive is this disabled only for user code of system does not use it too?

the good thing about MONITOR you write is what i think too - hardware support of great syncing usage -especially the MONITOR

becouse insted of MWAIT hang i think there should be probably something else, - i do not know - just the thing for doin nice hardware synchronizing support

(well maybe i mistake the monitor way of working aobve

a little, probably to work monitor must wait, but do not matter)

PS:

O not to much knowledgeable in this things but it seems to me that if this would work this could be used :

if first processor is working in some ram area second must stop at some lock byte. As i seen it, it has a choice to context switch to another work, and come here l8er, or try to spin-check the lock : spin check for a while maybe would be a better option in some cases (though maybe not to much -

i do not know ,depends on overall cost of switching the task,

which i do not know how large it is, maybe not to large)

and when doing this spin-check maybe it would be better

to monitor-and-wait ? though maybe it is not to usefull because this spin checks shouldnt be probably large at all,

so tey are probably not a big waste monitof-mwait could save

- besides it is nice to find some hardware attempts to help

here - maybe processors should support context switching

at hardware lewel more at all -it seem to me that today it is

mostly software - but as i said i am not tomuch knowledgeable here