> On Thursday 29 August 2002 16:46, you wrote: > > The first three bytes of the name of a rwlock/mutex/semaphore/condvar etc > > are interpreted as the type identifier, the rest of the rid0x83daf50 > > string above is assumed to be the actual address of the thing! No > > further checking is performed by GetObj() to ensure that the provided > > address is actually correct, so you can make up any address you like and > > pass it to ns_rwlock or ns_mutex or whatever with the destroy sub-command > > and have the memory so pointed to over-written! > > How would you avoid this? You'd have to introduce a table > for matching handle and pointer and get another mutex > arround that table. This would of course have impact on > speed. So either you have speed, or you're very safe. >
I don't think that something that can crash AOLserver so easily should be preferred in favour of "speed". In my case I had a tcl bug that tried to delete an ns_rwlock twice, but I couldn't find the bug because on the second call to ns_rwlock destroy AOLserver crashed. I have implemented a semi thread safe fix for this. It uses a small fixed size hash table (not a Tcl one) and little linked lists to keep track of the objects that are in use and valid. SetObj() and 2 new functions CreateObj() and DeleteObj() are thread safe, because they change the data structure. The performance penalty of this should be negligible as creation/deletion of mutexes etc. is a comparatively rare event. GetObj() isn't thread safe, but I can justify this as follows: 1. If a new object is being put in the data structure, no other thread could possibly know about it, so it does no harm. 2. If a thread finds an object that another thread is in course of deleting, the lower level thread object is already invalid, and I'm assuming that the operations on the lower level object will recognize that it is invalid. The GetObj() performance penalty should be very small, a few bit operations, and a traversal of a short linked list. Unless you have a huge number of mutexes etc. the linked list will only have a few items in it. Our typical operating set up has about 25,000 rwlocks and mutexes and a small number of semaphores so I would expect each list (there are 256) to have about 100 elements. If anyone is interested in my fix, send me an email and I'll gladly forward my version of nsd/tclthread.c -- -- Harry Moreau ----------------
