Почему в Windows CE .NET 4.2 может зависать SetTimeZoneInfo? - PullRequest
Новая
       36

Почему в Windows CE .NET 4.2 может зависать SetTimeZoneInfo?

2 голосов
/ 05 января 2009

Наш продукт содержит систему диспетчера задач, которая позволяет приложениям запускать код в DLL через запланированный интервал, указывать правила о том, должен ли сбой задачи отключать связанное приложение, и т. Д. В основном он используется для загрузки данных, загрузка данных, обслуживание локальной базы данных и т. д. Одна из используемых функций заключается в синхронизации времени устройств через NTP и установке информации о часовом поясе ОС. Для этого мы используем класс DateTimeHelper в OpenNetCF, который, похоже, служит оболочкой для Win32 P / Invokes.

Одной из других функций диспетчера задач является то, что если задача выполняется дольше, чем ее выделенное временное окно, диспетчер задач выполнит Thread.Abort (), чтобы разрешить выполнение других задач. Мы видим тревожное число прерываний потока, в которых самая высокая функция в стеке - OpenNetCF.WindowsCE.NativeMethods.SetTimeZoneInformation (). Почему базовый P / Invoke (SetTimeZoneInfo) зависает так долго?

Наш код работает на Windows CE 4.2 и с гораздо меньшей пользовательской базой на Windows CE 5.0 - код здесь одинаковый между двумя версиями. До сих пор я видел, что это происходит на устройствах 4.2, но никогда на 5.0, и даже при меньшем количестве пользователей на 5.0, я думаю, я бы видел, если бы он присутствовал там.

Функция ниже - это функция, из которой вытекает проблема. Он преобразует сокращение часового пояса в его полное имя, затем использует имя для поиска правильного часового пояса и пытается установить текущий часовой пояс устройства на этот. 

        public static bool SetTimeZone(string timeZoneAbbreviation)
        {
            string TimeZoneInfo = string.Empty;
            bool timeZoneChanged = false;

            switch (timeZoneAbbreviation)
            {
                case ALASKA:
                    TimeZoneInfo = ALASKA_TZN;
                    break;
                case ALASKA_ALT:
                    TimeZoneInfo = ALASKA_TZN;
                    break;
                case ATLANTIC:
                    TimeZoneInfo = ATLANTIC_TZN;
                    break;
                case ATLANTIC_ALT:
                    TimeZoneInfo = ATLANTIC_TZN;
                    break;
                case CENTRAL:
                    TimeZoneInfo = CENTRAL_TZN;
                    break;
                case CENTRAL_ALT:
                    TimeZoneInfo = CENTRAL_TZN;
                    break;
                case EASTERN:
                    TimeZoneInfo = EASTERN_TZN;
                    break;
                case INDIANA:
                    TimeZoneInfo = INDIANA_TZN;
                    break;
                case HAWAII:
                    TimeZoneInfo = HAWAII_TZN;
                    break;
                case MOUNTAIN:
                    TimeZoneInfo = MOUNTAIN_TZN;
                    break;
                case ARIZONA:
                    TimeZoneInfo = ARIZONA_TZN;
                    break;
                case PACIFIC:
                    TimeZoneInfo = PACIFIC_TZN;
                    break;
                case PACIFIC_ALT:
                    TimeZoneInfo = PACIFIC_TZN;
                    break;

                default:                    
                    break;
            }

            TimeZoneInfo += "\0";

            TimeZoneCollection tzc = new TimeZoneCollection();
            tzc.Initialize();

            foreach (TimeZoneInformation tzi in tzc)
            {
                string tzDisplayName = tzi.DisplayName.TrimEnd(new char[]{'\\','0'});

                if (tzDisplayName.ToUpper(CultureInfo.CurrentCulture).Equals(TimeZoneInfo.ToUpper(CultureInfo.CurrentCulture)))
                {
                    DateTimeHelper.SetTimeZoneInformation(tzi);
                    System.Globalization.CultureInfo.CurrentCulture.ClearCachedData();
                    timeZoneChanged = true;
                    break;
                }
            }

            return timeZoneChanged;
        }

Спасибо как всегда за вашу помощь. Есть мысли?

1 Ответ

1 голос
/ 05 января 2009

Вызов DateTimeHelper.SetTimeZoneInformation представляет собой очень тонкую оболочку вокруг P / Invoke для SetTimezoneInformation API (я только что проверил это в источнике). Он в основном выполняет вызов и проверяет код возврата - ничего более, так что в значительной степени исключает сам SDF как основную причину.

Далее, глядя на документ MSDN для SetTimezoneInformation , это действительно простой синхронный вызов, который возвращает TRUE или FALSE. Это говорит мне о том, что API, вероятно, также не является основной причиной.

Одна вещь, которую нужно помнить в CE, это то, что вы можете никогда предполагать, что платформа безупречна, потому что она сделана OEM и, следовательно, может иметь вариации. Тот факт, что вы видите сбой в 4.2, а не 5.0, заставил меня проверить следующее:

  1. Убедитесь, что к образу устройства 4.2 применены все QFE
  2. Посмотрите, есть ли разница кода ОС между 4.2 и 5.0 для часового пояса (я сомневаюсь, но у меня больше не установлен PB 4.2).
  3. Проверьте реализацию OEM для установки времени. Изменение зоны неявно делает вызов, чтобы установить время, и, возможно, в 4.2 BSP есть ошибка, которая имеет потенциальную блокировку или расу, на которую вы попали.
...