|
|
Home » U++ Library support » U++ MT-multithreading and servers » Core multithread dangers
Core multithread dangers [message #835] |
Fri, 03 February 2006 23:09 |
hojtsy
Messages: 241 Registered: January 2006 Location: Budapest, Hungary
|
Experienced Member |
|
|
I was told before that Core & Web packages are thread-safe. But some methods of Core are not thread-safe, and something like
CriticalSection::LockMain should be added to them to fix this. Here is a list of them.
static TimingInspector& s_zero()
TimingInspector::TimingInspector(const char *_name)
static void sInit()
String& sHomeDir()
String ConfigFile(const char *file)
byte *Alloc4KBRaw()
void *MemoryAllocPermanent(size_t size)
void *MemoryAlloc(size_t size)
void MemoryProbe(const char *name, dword flags)
const LanguageInfo& GetLanguageInfo(int lcode)
static Array<LngModule>& sMod()
CriticalSection& MainCriticalSection()
PageInfo *NewPage(int magnitude)
static CriticalSection& sHeapLock()
static CriticalSection& sHeapLock2()
static inline void sInitTables()
void MemoryInitDiagnostics()
RHITCOUNT(n)
static int sMappingGranularity_()
VectorMap<String, VectorMap<String, VectorMap<String, Topic > > >& TopicBase()
String GetIniKey(const char *name)
These other functions of Core need bigger rewrite to be threadsafe:sDumpPtr(void *ptr)
sDump(dword w)
const char *Dump(PageInfo *page)
const char *MemoryCounters()
These functions of the Web package are not thread-safe:
void HttpServer::ReadPostData(Socket& socket, HttpQuery& query)
void SSLInit()
static const dword *GetCRCTable()
RefPtr<HttpQuery::Data> HttpQuery::Empty()
dword WINAPI HttpExtensionProc(EXTENSION_CONTROL_BLOCK *ecb)
The problem is always with the local static variables which are not protected from parallel initialization on two threads.
|
|
|
|
|
|
|
Re: Core multithread dangers [message #868 is a reply to message #845] |
Mon, 06 February 2006 11:46 |
|
mirek
Messages: 13980 Registered: November 2005
|
Ultimate Member |
|
|
Hojtsy, I have one MT trouble I would like to share....
It is about Ptr implementation. While current version is MT safe to my knowledge, it is inferior to previous one as it allocates shared data for the lifetime of Pte target.
Original version was able to delete shared data whenever no more pointer were pointing to it, something like
release prec:
if(--prec->n == 0) {
// MT!
prec->ptr->prec = NULL;
delete prec;
}
However, I do not see a way how to implement it without adding a lock to Pte, which is even worse. The trouble is that at the MT! point, Pte can be destructed and prec is not valid anymore....
(Just for record, ~Pte() { if(prec) prec->ptr = NULL; })
Hm, thinking about it, maybe single _global_ lock would do?
Mirek
|
|
|
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Thu May 16 18:14:49 CEST 2024
Total time taken to generate the page: 0.02593 seconds
|
|
|