Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 13 down vote favorite

I've spent 3 days debugging one very obscure bug in a library made by my colleague, this bug happens very infrequently. After all I found that this bug happens due to cross-thread access to an object without any lock. Actually this is not a first bug of this kind, there were similar bugs before. He just runs his unit tests, and if something fails puts somewhere a lock. And if nothing fails, ughm, then his code is perfect. It seems he has no idea about threading safety. I'm 100% sure there are many similar bugs that just haven't surfaced yet. It seems PM doesn't understand threading stuff too.
The problem is, he works much more time in the company than I do. Anyway, I can't just say "this guy is incompetent in this area", because this always shows you as a "bad team player", etc.
Any ideas, what I can do?

share|improve this question
What country is this? – user1249 Apr 22 '12 at 10:14
It's international company. – tika Apr 22 '12 at 11:23
If it's really a big issue and you are 100% certain that your colleague is making a mistake, first thing is to politely point it out in such a way that he isn't threatened. The second thing is, if your colleague doesn't listen, is just to point out the potential damages in cash. That's what all managers listen to, and very carefully at that. Having a threading problem such as you described is potentially very harmful, and unless you're 100% certain in your statements, go forward with them. – N.B. Apr 23 '12 at 8:50
Likely belongs on the Project Management SE site. – Bernard Apr 23 '12 at 16:25
The Project Management SE site does not have a "Multithreading" tag, which this question should have. – RalphChapin Apr 24 '12 at 1:18

closed as not constructive by gnat, Walter, GrandmasterB, Robert Harvey, Bernard Apr 23 '12 at 15:34

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.

4 Answers

up vote 10 down vote accepted

Convince PM that to avoid such bugs, the know-how of the team about threading stuff should be improved, and tell them that you are willing to organize something like a workshop or a presentation about it. Don't make it a personal thing between you and your colleague.

share|improve this answer
I'm afraid this won't be welcome by that guy, because he thinks he is professional in this area (and can teach everyone himself). But I can try. – tika Apr 22 '12 at 9:04
Ah yes, and one big problem - English is not my native language, I speak not very well. – tika Apr 22 '12 at 9:12
If both your colleague and PM have limited knozledge of threading, and thread safety, then training is definitely the best approach. It's not one guy's incompetence - it's the team's competence that is the problem. – boisvert Apr 22 '12 at 10:37
A workshop is something where all of you can throw in their knowledge, and all of you should learn something from it. If your colleague thinks he knows something about threading, perhaps you can learn some things from him, too. – Doc Brown Apr 22 '12 at 13:49
up vote 7 down vote

Write a unit test that shows the bug and ask him to fix it.

share|improve this answer
1  
He already aware of this bug. He just can't find the reason. – tika Apr 22 '12 at 7:26
Didn't you found the reason in the three day debug session? Or do I read your question incorrectly? – user1249 Apr 22 '12 at 7:49
1  
@scarfridge Depends on the platform. For Java you can use byte code instrumentation or Aspect oriented programming to insert a wait exactly where the problem is, (or use JVMTI to control the execution). It is possible to do! – user1249 Apr 22 '12 at 9:53
1  
It's not only matter of sequence. Many other factors are involved - which cores execute code, when GC occurs and how it moves objects, how changes are propagated from one core's cache to another, etc. – tika Apr 22 '12 at 11:22
1  
Actually it's just a set of method calls repeated billions of times. But this doesn't matter much. The real reason is access to a dictionary object from 2 threads without lock (i.e. without memory barriers). Thread A creates it, thread B reads it. – tika Apr 23 '12 at 2:19
show 17 more comments
up vote 4 down vote
  • It's a senior developer's job to review his code and suggest improvements.
  • You are not there to check after his work, I would personally hate if somebody was re-checking all my changes to see if anything broke
  • If he doesn't accept your advise, then it's PM's job to fix the communication issue.
  • Threading issue in a unit test makes me wonder whether this test is actually a unit test, rather than integration or component test.
share|improve this answer
I get your idea. Obey your command. – tika Apr 22 '12 at 9:05
2  
What does it matter if a test showing an issue is called "unit test" or "integration test"? The whole situation remains the same. – Doc Brown Apr 22 '12 at 14:09
1  
My concern is that his colleague might not know the difference between the unit and component test, therefore further training might be required to address this issue. – CodeWorks Apr 22 '12 at 14:12
@CodeRush - I take it you do not believe in peer review? What would it take for you to actually appreciate that somebody else was rechecking your code (as opposed to just crash in production)? – user1249 Apr 23 '12 at 6:00
I get the idea, but I haven't seen it working effectively in my previous jobs. I think that reviews by a senior developer is a better feedback mechanism. – CodeWorks Apr 23 '12 at 7:52
up vote -3 down vote

I think your company should not be using multithreading.

After doing a massively multithreaded project, I found two techniques were critical to making things work. First, the code had to be written right. Every field had to be manually checked to make sure it was declared properly and properly synchronized whereever referenced. (Warning: I am simplifying things a bit here to keep my answer short--or at any rate, shorter.) Second, the code had to be tested by running it flat out on single and multicore machines--many minutes using 100% of each core. (And if it only uses 2% of each core, as it often did for me, that's a bug too.)

You might be able to manage this, but your organization can't. Even if they understood the problem, which they don't, they don't have the expertise.

Most languages provide ways to avoid this. If you have a socket reader, which usually has its own thread, have it get the info to the main thread as quickly and simply as possible. Better yet, look for system classes/functions that will handle the thread-part of the reading for you. Use a queue that runs "events" one after the other, like most GUI API's do. (Use the GUI API's event queue itself, for that matter.) If you need parallel processing, you can probably find some kind of "worker thread" that will let you keep data/fields in a single thread, handling all transfers for you.

Emphasise to all the dangers of multithreading. (Scary stories: My favorite bug involved a couple of lines like: int i = 5; i = i * i;, which resulted in i having a value of 35. One I saw a lot was: if (thing != null) thing.reset(); throwing a null pointer exception.) I think your only hope is making them understand they're stepping into a whole, new, strange world, and that maybe they should take one big step back.

I'm not real sure how multithreading should be handled. If the job can be given to one person, and everything they do thrown away if they fail, fine. But a team is only going to be as strong as its weakest member, and even a good programmer will have trouble with full-blown multithreading. I hope the language people will find a way to make it safe. I have seen some helpful software out there. But I think it best to avoid multithreading unless execution time is critical and a good programmer or a proven team is available.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.