Subj : Re: Can C++ local static objects be made thread safe? To : comp.programming.threads From : Giancarlo Niccolai Date : Sat Feb 05 2005 01:05 am Marcin 'Qrczak' Kowalczyk wrote: > Giancarlo Niccolai writes: > >>>> Suppose that read_unicode_database_from_file() requires ANOTHER static >>>> initializer, or is replaced in the MT code with something different. In >>>> example, suppose that read_unicode_database_from_file() requires a >>>> locked variable to be prepared by the thread that calls >>>> lookup_unicode_char_by_name(). Then, chances are that >>>> read_unicode_database_from_file() will deadlock. >>> >>> If there was a cyclic dependency between local static objects, then the >>> library would have been already broken in a single-threaded environment. >> >> The cyclic dependency is introduced in MT code; ST code cannot have >> cyclic dependency. > > If you introduced a cyclic dependency, you broke the code, and it has > nothing to do with making initialization of static local objects > thread-aware. > > Please show how it's broken when thread local static objects are > initialized in a thread-aware way, and at the same time it works when > they are initialized using an traditional guard variable. Thread-aware way do not mean locked; it may require locking it may not require it, it may suffice or not. The BAD thing is that THIS kind of blind-locking may get in the way of the CORRECT way to secure your code, preventing you from really doing so. I am sorry, but if you don't get this, I cannot absolutely do nothing more to help you. Your correct ST code may need some deeper function that needs to be changed in MT for any reason. So, when you say "you have introduced cyclic redundancy so you broke the code", I don't buy it, and you should not too. It's you that asked the NG a while ago how to make some functions to work with the same semantic under ST and MT by just linking a different, MT aware version in MT mode. So, you have already met the problem of ST code needing a deeper layer that may get differently handled (even if it looks the same) in MT. What this different MT base layer will do cannot be abstrcted for the "general situation"; surely, it cannot be told for sure by a compiler in its compilation step. Now, are you finally on this? > >> In example, are you really sure that it's a "smart" programming technique >> to open and setup a database environment as a by-product of a very >> commonly used routine? How will you manage errors? With try-catches? are >> you really sure you want to try-catch all your access to a >> unicode-translation functions to prevent a lazy initialization failure to >> abort your program? > > This has nothing to do with MT. If you don't like static local > variables with non-trivial initialization, don't use them, but why do > you advocate a broken semantics of these variables when they are used > in multiple threads? I just state that using this semantic MAY require different treatment than just a compiler provided locking; actually I do state that this (the blind lock not being enough/being a problem) is the most common situation, but that's not the point. > >> I repeat myself, but you are trying to solve an unexisting problem; >> correctly built MT programs just works another way, and ST programs going >> MT just must be redesigned in some area; > > Not all programs must be redesigned. There is a chance that making > initialization of local static objects thread-aware is the only thing > needed to make them working. > In fact, "not all program", and "there is a chance" are the key of that. I am not trying to demonstrate that all the code will be broken with this addition, I am just telling you that this addition cannot make every possible ST code that may be initialized that way threadsafe in MT context, and that some correct MT code may get broken. Don't you think that this arguments are enough to suggest that an eventual "blind locking" should be, if ever done by the compiler, at least an option? Because THIS is what I've been trying to explain up to date. Gian. .