StephenM

I'm looking for best practices or guidance for the following scenario. The front end is a page control with multiple pages. The user completes the form and presses 'Save'. The app takes the contents of the controls, populates an XML document, and sends the document to a server for validation and processing. Let's say a validation error occurs. One of the XML fields contained a negative number and only positive numbers are allowed. How does the client know which page and control to highlight for a given validation? I think there needs to be some association between the data entry controls and the XML fields, but I'm unsure what is the best way to build this. Have you handled this situation before? What algorithm or data structure did you use? Regards, Stephen

Hello Gabr, I'm seeing a race condition in TOmniResourceCount in the TryAllocate function. I created a logger following your advice in: https://stackoverflow.com/questions/8134526/implement-thread-safe-logging Two methods in the TOmniLogger code relevant to this discussion are: procedure TOmniLogger.Log(const Text: string); begin FLogQueue.Enqueue(Text); FLogMsgCount.Allocate; end; procedure TOmniLogger.Logger(const task: IOmniTask); var LogFile: TOmniLogFile; procedure Flush; var logData: TOmniValue; begin while FLogQueue.TryDequeue(logData) do begin FLogMsgCount.Release; LogFile.Log(logData.AsString); end; end; begin LogFile := TOmniLogFile.Create(FFileName); FTaskName := Format('%s:%s [ThreadId:%d]', [Self.ClassName, SysUtils.ExtractFileName(FFileName), Windows.GetCurrentThreadId]); try Log(Format('Task "%s" on thread [%d, %d]', [Task.Name, Task.UniqueID, Windows.GetCurrentThreadId])); while DSiWaitForTwoObjects(task.TerminateEvent, FLogMsgCount.Handle, false, CMaxLogTimeout_ms) <> WAIT_OBJECT_0 do Flush; Flush; finally LogFile.Free; end; end; FLogMsgCount is an instance of TOmniResourceCount. The race condition occurs in the tight while DSiWaitForTwoObjects loop and involves FLogMsgCount.Handle. This code calls two methods from TOmniResourceCount in OtlSync.pas, Release and TryAllocate: function TOmniResourceCount.Release: cardinal; begin orcLock.Acquire; try Result := cardinal(orcNumResources.Increment); if Result = 1 then begin ResetEvent(orcHandle); SetEvent(orcAvailable); end; finally orcLock.Release; end; end; { TOmniResourceCount.Release } ///<summary>Like Allocate, but with a timeout.</summary> function TOmniResourceCount.TryAllocate(var resourceCount: cardinal; timeout_ms: cardinal): boolean; var startTime_ms: int64; waitTime_ms : int64; begin Result := false; startTime_ms := DSiTimeGetTime64; //TODO: Rewrite this with a faster, non-locking clock orcLock.Acquire; repeat if orcNumResources.Value = 0 then begin orcLock.Release; if timeout_ms <= 0 then Exit; if timeout_ms = INFINITE then waitTime_ms := INFINITE else begin waitTime_ms := startTime_ms + timeout_ms - DSiTimeGetTime64; if waitTime_ms <= 0 then Exit; end; if WaitForSingleObject(orcAvailable, waitTime_ms) <> WAIT_OBJECT_0 then Exit; // skip final Release orcLock.Acquire; end; if orcNumResources.Value > 0 then begin Result := true; resourceCount := cardinal(orcNumResources.Decrement); if resourceCount = 0 then begin ResetEvent(orcAvailable); //reset before release - otherwise there's a race condition between this code and .Release orcLock.Release; //prevent race condition - another thread may wait on orcHandle and destroy this instance SetEvent(orcHandle); Exit; // skip final Release end; break; //repeat end; until false; orcLock.Release; end; { TOmniResourceCount.TryAllocate } Here's the scenario where I see the race condition occurring: 1) resourceCount is 0. This code executes in TryAllocate: if resourceCount = 0 then begin ResetEvent(orcAvailable); //reset before release - otherwise there's a race condition between this code and .Release orcLock.Release; //prevent race condition - another thread may wait on orcHandle and destroy this instance SetEvent(orcHandle); Exit; // skip final Release end; 2) After the orLock.Release and before the SetEvent a thread switch occurs. 3) A call to TOmniResourceCount.Allocate is made via the TOmniLogger.Log procedure above. ResetEvent(orcHandle) is called. 4) A thread switch occurs. Now SetEvent(orcHandle) in TryAllocate executes. This causes: while DSiWaitForTwoObjects(task.TerminateEvent, FLogMsgCount.Handle, false, CMaxLogTimeout_ms) <> WAIT_OBJECT_0 do Flush; To execute. The end result is FLogMsgCount.Handle is stuck in the signaled state and this loop takes over a core. My workaround is to move the SetEvent(orcHandle) into the critical section (before orcLock.Release in TryAllocate), thus preventing this scenario. Does this seem like the correct approach to you? Regards, Stephen