Cam.onUpdate();

obj.onUpdate();[/quote]
Does any of these two calls lock inside?

P.s.: I tried other variants with Semaphores and Mutex but none of them solved the deadlock problem[/quote]

The proper way to fix this is to light 4 candles.


Deadlocks occur when locks are acquired in different order. If there are two threads acquiring A->B and B->A, then a deadlock will occur. If locks are always acquired in same order, it won't.


The overall design is incredibly fragile as well. It can be made to work right, but requires a lot of infrastructure in place. Event-based callbacks are essentially a no-go for threaded code.

Instead, there's a simple solution:
List<Something> updates;

while (running) {
List<Callbacks> callbacks;
lock(updates) {
// add everything from updates to objectList
// add all added objects to callbacks
updates.clear();
}

// fire onAdded events for all items in callbacks

doCalculations();
}

void addObject(...) {
lock(updates) {
updates.add(...);
}
}
[/font]


[font=arial,helvetica,sans-serif]Such design is robust and cannot deadlock. Converting it to actual C# code left as exercise to the reader.[/font]

I tested it with the sleeps in the locked sections, and i got an exception: "object synchronization method was called from an unsynchronized block of code"

That TryEnter looks suspicious. You should be checking its return value.
[/quote]

Indeed! This is exactly what will cause that exception; If TryEnter fails (or if you forget to call Enter/TryEnter at all), calling Exit throws that exception. The reason it is failing now is because your sleep in the other thread is keeping the wait handle locked for a much longer time, allowing TryEnter to fail more easily.

why should i fire an event "onAdded" when the Object is always in my ObjectList? Or... should each object which detects that it has to be updated by the driver fire an "Add" or "Calulate" event? [/quote]

I merely demonstrated on how to dispatch callbacks. Instead of doing it from main loop from inside a lock (each callback may take a long time, acquire locks and such), you instead defer them so they can run later outside of a lock.

The events you have are onUpdate(), executed from inside a lock. Instead, prefer to use the example above. While inside a lock, put the objects to be notified into a queue, then notify them without holding a lock.