Trying to resolve a locking thread

[ahmd]

I was just trying to make it more readable for people, that's it. If I put it as you did, people would start asking me, "What's in RAII lock?" when it's clearly not the issue here. I knew right off the get-go that someone would pick on the synchronization part and that is why I added this line in my original statement, "PS. Please note that I'm not asking to check if my process of synchronization between threads is correct."

Also what not to know about RAII -- you simply utilize a language destructors to ensure that operations that may require release/deallocation are performed. This simply rids a sloppy programmer of a possible trouble of creating a memory leak or not releasing a lock, or missing it because of an exception. That's it. This is not a panacea since many computer languages don't even support such concept. And speaking of exceptions, the most common one that can make APIs fail is a low memory exception, but guess what, if it's thrown in one place, it is most certainly guaranteed to cascade down the program in other places so it is practically impossible for a program to get out of it gracefully. Try it on some older system, the Windows will lock up and your program's behavior won't even matter.

[Arjay]

With respect to RAII, you seem misunderstand its benefit otherwise you wouldn't say it's for sloppy programmers only (thanks for the dig btw. ).

The whole point of RAII is so the programmer doesn't have to check every single code path and/or exception to ensure objects are getting unlocked.

As programs increase in complexity, it becomes more and more difficult to sync without using RAII - it's not about sloppy programming, it's about smart programming. So why not use a technique that ensures that all locks are released under any condition?

As far as your not wanting to discuss synchronization, I don't understand why not.

Issues with multithreading almost always boil down to improper synchronization. So understanding how you are synchonizing is always relevant (even if you think you don't have an issue).

Another area that the code can be improved (over manual locking/unlocking) is to use encapsulation as I've mentioned several times before.

Simply putting all the thread synchronization code into a single class and exposing thread-safe setters and getters will eliminate the majority of theading issues.

Now since this isn't the first time you've posted about having trouble with threading, I have to wonder why the advice of RAII/encapsulation isn't being followed (or perhaps you misunderstand and think it's being followed).

[ahmd]

Arjay, come on. I am following everything you just said. I don't know why you keep repeating it? That sample I posted above is employing your principle of encapsulation. Did I not call those methods a "getter" and a "setter"? I also keep repeating for you that I removed WaitForMultipleObjects() and ReleaseMutex() APIs from a RAII struct (or a class if you'd like to call it that way) for readability here and you keep telling me that I don't understand it

I agree with most of what you said but unfortunately the resolution to my problem seems to be a call to SendMessage that was locking one of the threads. (Or at least I hope so. I keep my fingers crossed, since I still haven't heard of the problem repeating after I put PostMessage instead.)

[Arjay]

GetWindowLongPtr(GWL_STYLE), SetWindowLongPtr(GWL_STYLE) and SetWindowPos use SendMessage internally. Even if it did, it wouldn't be posting to your apps msg queue anyway.

In my experience, there's never a need to use SendMessage when working with threads. I know that some developers use it to pass data between threads, but I don't like to involve windows messaging with threads because message processing is dependent on the types of message being sent and other messages can be sent in a higher priority than a user message (and therefore interrupt when a user message gets processed).

For threading, I only will ever post a message strickly to notify a UI thread that some state has changed. The data is only ever passed via a controller class that offers thread safe data accessor methods.

[ahmd]

GetWindowLongPtr(GWL_STYLE), SetWindowLongPtr(GWL_STYLE) and SetWindowPos use SendMessage internally. Even if it did, it wouldn't be posting to your apps msg queue anyway.

I'm sorry, did you mean to say that they do, or they don't?

As for my use of Post/SendMessage then yes, this is to notify a GUI element in the main thread. I don't pass it on a regular basis during a normal operation, but only when a thread terminates. It is used to hide a common control element.

[Arjay]

They don't.

[ahmd]

They don't.

Arjay, sorry to contradict you. I just got to the part of the code that locks up. (Took me a while to replicate it in a debugger, so it's 100%) Here it is:

SetWindowLongPtr(GWL_STYLE);

My only explanation why this happens is because it calls SendMessage to the main GUI thread internally.

[Igor Vartanov]

It's very and very unlikely. SetWindowLong must talk directly to kernel, and I cannot imagine even a single reason why it should use messaging.

[ahmd]

It's very and very unlikely. SetWindowLong must talk directly to kernel, and I cannot imagine even a single reason why it should use messaging.

Igor, I'm 100% positive. I've tried it several times with a debugger and that particular line locks up the worker thread it's called from. In it I'm enabling the WS_VISIBLE flag for a UI control from the main thread. Whatever it does internally is similar to the SendMessage behavior.

[Igor Vartanov]

and that particular line locks up the worker thread it's called from. In it I'm enabling the WS_VISIBLE flag for a UI control from the main thread.

So this naturally brings us to the idea of doing it in main thread. I mean, after posting custom message of course.

[ahmd]

So this naturally brings us to the idea of doing it in main thread. I mean, after posting custom message of course.

Yeah, this seems like what I'll end up doing. It's just so much rewriting that I'll have to subject myself to... Plus posting messages back and forth doesn't really go well (or fast) with the GUI stuff.

So, the bottom line is that it's generally not a good practice to call any API that may be dealing with a UI element from a thread other than the main, is that correct?

PS. Now I don't know what other APIs may also lock up, since there's clearly not a word about it in the documentation.

[Arjay]

So, the bottom line is that it's generally not a good practice to call any API that may be dealing with a UI element from a thread other than the main, is that correct?

Wow, you're just now figuring out that you shouldn't access UI components from worker threads? This surprises me since you've been told this many times in many different posts where you've had threading issues.

Glad you're starting to get a handle on this.

[Codeplug]

http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx
http://blogs.msdn.com/b/oldnewthing/...8/6882760.aspx

gg

[Igor Vartanov]

posting messages back and forth doesn't really go well (or fast) with the GUI stuff.

Not sure where this comes from. My experience tells me opposite.