13

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?

Improve this question
6
  • What country is this?
    – user1249
    Apr 22, 2012 at 10:14
  • It's international company.
    – tika
    Apr 22, 2012 at 11:23
  • 2
    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, 2012 at 8:50
  • Likely belongs on the Project Management SE site.
    – Bernard
    Apr 23, 2012 at 16:25
  • 1
    The Project Management SE site does not have a "Multithreading" tag, which this question should have.
    – RalphChapin
    Apr 24, 2012 at 1:18

4 Answers 4

Reset to default
13

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.

Improve this answer
4
  • 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, 2012 at 9:04
  • Ah yes, and one big problem - English is not my native language, I speak not very well.
    – tika
    Apr 22, 2012 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, 2012 at 10:37
  • 1
    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, 2012 at 13:49
8

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

Improve this answer
22
  • 1
    He already aware of this bug. He just can't find the reason.
    – tika
    Apr 22, 2012 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, 2012 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, 2012 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, 2012 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, 2012 at 2:19
4
  • 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.
Improve this answer
6
  • I get your idea. Obey your command.
    – tika
    Apr 22, 2012 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, 2012 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.
    – CodeART
    Apr 22, 2012 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, 2012 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.
    – CodeART
    Apr 23, 2012 at 7:52
-5

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.

Improve this answer
4
  • 2
    You have no idea what company it is, or what they're doing, so the comment "You might be able to manage this, but your organization can't" is a bit unfounded - for all you know, tika could work at Microsoft. Whoever they are, multithreading may well be the best way to solve their problem; there are plenty of situations where it fits. And putting all that aside, the question isn't about multithreading, it's about handling a colleague who's causing problems due to a lack of expertise.
    – anaximander
    Aug 21, 2013 at 9:31
  • @anaximander: Multithreading produces bugs that are very hard to reproduce and so very hard to track down. To produce usable, fixable MT software, you will need, at a minimum, to have programmers and management that are aware of the dangers. Tika's organization plainly could not handle this. I've seen testing/QA people force programmers to write sound code by testing heavily and demanding fixes for every bug. That doesn't work with MT. If the colleague lacks ability, interest, and motivation, handle him by keeping him away from MT.
    – RalphChapin
    Aug 21, 2013 at 23:43
  • @anaximander: You must have had better experiences with Microsoft than I've had. Though to be fair, I've never seen anything that looked like a mutlithreading bug from them. ....And thanks for the comment.
    – RalphChapin
    Aug 21, 2013 at 23:47
  • 1
    Regardless, when the question is "how do I handle a colleague who lacks expertise?", I don't think "your company is building software wrong" is a valid answer. In any organisation, no matter how vast and knowledgeable, there will always be those with gaps in their knowledge. Without knowing the who organisation is or what the software is doing, I don't think you can reliably make the judgement that the company doesn't know what they're doing, or that their problem can be solved without multithreading.
    – anaximander
    Aug 22, 2013 at 8:04

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