Лучше опросить или подождать?
Вы можете сделать это с помощью jQuery
$("select").addClass("form-control")
здесь, выбрать тег ishtml, имя класса управления формами
@Html.DropDownList("SupplierId", "Select Supplier")
и здесь, SupplierId - ViewBagList , Select Supplier - Отображаемое имя
7 ответов
Provided the OS has reasonable implementations of these type of concurrency primitives, it's definitely better to wait on a kernel object.
Among other reasons, this lets the OS know not to schedule the thread in question for additional timeslices until the object being waited-for is in the appropriate state. Otherwise, you have a thread which is constantly getting rescheduled, context-switched-to, and then running for a time.
You specifically asked about minimizing the processor time for a thread: in this example the thread blocking on a kernel object would use ZERO time; the polling thread would use all sorts of time.
Furthermore, the "someone else is polling" argument needn't be true. When a kernel object enters the appropriate state, the kernel can look to see at that instant which threads are waiting for that object...and then schedule one or more of them for execution. There's no need for the kernel (or anybody else) to poll anything in this case.
Ожидание - это более «приятный» способ поведения. Когда вы ожидаете объект ядра, вашему потоку не будет предоставлено процессорное время, так как планировщику известно, что работа не готова. Вашему потоку будет предоставлено процессорное время только тогда, когда будет выполнено условие ожидания. Это означает, что вы не будете напрасно загружать ресурсы процессора.
Я думаю, что вопрос, который еще не поднимался, заключается в том, что, если вашей ОС предстоит много работы, блокирование передачи вашего потока другому процессу. Если все процессы используют блокирующие примитивы там, где они должны (например, ожидание ядра, файловый / сетевой ввод-вывод и т. Д.), Вы даете ядру дополнительную информацию, чтобы выбрать, какие потоки должны выполняться. Таким образом, он выполнит больше работы за то же время. Если ваше приложение может делать что-то полезное, ожидая открытия этого файла или прибытия пакета, то вы можете даже помочь вашему собственному приложению.
Waiting does involve more resources and means an additional context switch. Indeed, some synchronization primitives like CLR Monitors and Win32 critical sections use a two-phase locking protocol - some spin waiting is done fore actually doing a true wait.
I imagine doing the two-phase thing would be very difficult, and would involve lots of testing and research. So, unless you have the time and resources, stick to the windows primitives...they already did the research for you.
Есть только несколько мест, обычно в пределах низкоуровневых вещей ОС (обработчики прерываний / драйверы устройств), где ожидание вращения имеет смысл / требуется. Приложениям общего назначения всегда лучше ждать некоторых примитивов синхронизации, таких как мьютексы / условные переменные / семафоры.
I agree with Darksquid, if your OS has decent concurrency primitives then you shouldn't need to poll. polling usually comes into it's own on realtime systems or restricted hardware that doesn't have an OS, then you need to poll, because you might not have the option to wait(), but also because it gives you finegrain control over exactly how long you want to wait in a particular state, as opposed to being at the mercy of the scheduler.
Waiting (blocking) is almost always the best choice ("best" in the sense of making efficient use of processing resources and minimizing the impact to other code running on the same system). The main exceptions are:
- When the expected polling duration is small (similar in magnitude to the cost of the blocking syscall).
- Mostly in embedded systems, when the CPU is dedicated to performing a specific task and there is no benefit to having the CPU idle (e.g. some software routers built in the late '90s used this approach.)
Polling is generally not used within OS kernels to implement blocking system calls - instead, events (interrupts, timers, actions on mutexes) result in a blocked process or thread being made runnable.