Re: Threading in Order?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Adam Benson wrote:
Unfortunately, the messages are not stored in order of occurrence.
What makes you say that? The time stamps are out of order? Or something else?

messages are stored in the order

If you want to ensure that if thread A calls the logging method just before thread B then thread A's message goes in the log first do something like this (pseudo code) : [code snipped]

Nope. You simply cannot do that. Each thread can get interrupted by the OS at arbitrary points. Just because thread A calls the LogAMsg() method before thread B does, that doesn't mean that thread A will acquire the lock before thread B; it could happen to get pre-empted just before acquiring the lock, with thread B running immediately after and acquiring the lock before thread A.

The best one can do is not generate a timestamp until the lock has actually been acquired, but then the timestamp winds up being not the time of the event being logged, but the time that the event _is_ logged. A subtle, but VERY important difference.

If you want the timestamp to reflect the time that the event actually _happened_, then it is not possible to guarantee with 100% certainty that the event is added to the event queue in the same order in which the event happened. You can reorder the events in the log once logging is done and you know no more events will be added, but while the logging is happening, it's just not possible. The thread scheduler is controlling things at a lower level than the managed application can affect.

Pete
.

Relevant Pages

  • Re: pessimistic locking
    ... >> Put a TIMESTAMP column on the table. ... >> If you really are convinced you want to lock the row, ... >> inserted into the data set by another user and are included in later ... This is the most restrictive of the four isolation levels. ...
    (microsoft.public.sqlserver.programming)
  • Re: Rowversion and locking
    ... can not lock it to any level above shared. ... right now it is the same as timestamp, ... with rowversion. ... > As for the trigger... ...
    (microsoft.public.sqlserver.programming)
  • Re: [PATCH] perf lock: Drop "-a" option from set of default arguments to cmd_record()
    ... injection will be really helpful thing. ... I think that making 3 or 4 events per each lock sequences ... timestamp of itself+ lock addr ... whole lock sequence, like in my above lock_contended example, ...
    (Linux-Kernel)
  • Re: [PATCH] perf lock: Drop "-a" option from set of default arguments to cmd_record()
    ... injection will be really helpful thing. ... >> I think that making 3 or 4 events per each lock sequences ... > by dependencies (take lock A and then take lock B under A, ... timestamp of itself+ lock addr ...
    (Linux-Kernel)
  • Re: unique id
    ... but how can i lock it so no one straight after can grab the same value ... If you need a timestamp, then store the timestamp as well. ... considered bad design practice to have one database field serving two ...
    (alt.php)