Если Вы используете jQuery:
$(function() {
$("#Box1").focus();
});
или прототип:
Event.observe(window, 'load', function() {
$("Box1").focus();
});
или плоскость JavaScript:
window.onload = function() {
document.getElementById("Box1").focus();
};
, хотя имеют в виду, что это заменит другой на обработчиках загрузок, поэтому ищите addLoadEvent () в Google для безопасного способа добавить onload обработчики вместо замены.
Как указано в комментарии, один из подходов - иметь фиксированный пул блокировок (скажем, 32) и брать идентификатор по модулю 32, чтобы определить, какую блокировку принять. Это может привести к ложному разделению блокировок. 32 - это число, выбранное с воздуха - оно будет зависеть от распределения значений идентификаторов, количества потребителей и т. Д.
Я бы рассматривал синхронизированную очередь FIFO как отдельный класс / синглтон для всех ваших созданных объектов - производители ставят объекты в очередь, а потребители удаляются из очереди - таким образом, фактические объекты больше не требуют никакой синхронизации. Затем синхронизация выполняется вне реальных объектов.
Можете ли вы сделать свои идентификаторы уникальными для каждого объекта? Если это так, вы можете просто заблокировать сам объект.
Во-первых,
вы профилировали, чтобы установить, что замок (_lockers)
действительно является узким местом? Потому что, если он не сломан, не чините его.
Edit: Я недостаточно внимательно прочитал, речь идет о (большом) количестве созданных вспомогательных объектов.
Думаю, у Дэмиена для этого есть хорошая идея, я оставлю немного о строках:
Относительно
NB: Тот же вопрос с идентификатором свойство имеет строковый тип (в этом может я смогу заблокировать string.Internal (currentObject.ID)
Нет, плохая идея. Вы можете заблокировать строку, но тогда вам придется беспокоиться о том, могут ли они быть интернированы. Трудно быть уверенным, что они уникальны.
Как насчет назначения идентификаторов из пула объектов идентификаторов и их блокировки?
При создании элемента:
var item = CreateItem();
ID id = IDPool.Instance.Get(id);
//assign id to object
item.ID = id;
пул идентификаторов создает и поддерживает общие экземпляры идентификаторов:
class IDPool
{
private Dictionary<int, ID> ids = new Dictionary<int, ID>();
public ID Get(int id)
{
//get ID from the shared pool or create new instance in the pool.
//always returns same ID instance for given integer
}
}
затем вы блокируете идентификатор, который теперь является ссылкой в вашем методе Consume:
private void Consume(T notif)
{
lock(notif.ID)
{
...
}
}
Это не оптимальное решение и только переносит проблему в другое место, но если вы считаете, что у вас есть давление на блокировку, вы можете получить производительность улучшение с использованием этого подхода (учитывая, что, например, ваши объекты создаются в одном потоке, тогда вам не нужно синхронизировать пул идентификаторов).
См. Как в: Синхронизация источника и потока потребителя (Руководство по программированию на C #)
В дополнение к простому предотвращению одновременный доступ с замком ключевое слово, дальнейшая синхронизация предоставляется двумя объектами событий. Один используется для сигнализации рабочим потокам прекращается, а другой используется поток производителя, чтобы сообщить потребительский поток, когда новый элемент имеет добавлен в очередь. Эти двое объекты событий инкапсулируются в класс называется SyncEvents. Это позволяет события, которые нужно передать объектам которые представляют потребителя и производитель легко выполняет потоки.
- Правка -
простой фрагмент кода , который я написал когда-то назад; посмотрим, поможет ли это. Я думаю, что это то, на что указывает weismat?
- Edit -
Как насчет следующего:
Создайте объект, скажем CCustomer, который будет содержать:
Словарь, который теперь будет содержать
, когда вы проверяете следующее
if(!_lockers.ContainsKey(id))
_lockers.Add(id,new CCustomer(/**bInProgress=true**/));
return _lockers[id]; **//here you can check the bInProgress value and respond accordingly**.