Tag Info

New answers tagged

4

There is no clean and safe way to quickly/efficiently "kill" a thread. You can signal to the thread object that it needs to terminate, but the thread needs to be written in such a way that it checks for this and then cleans itself up. Otherwise, you can end up with partially-completed operations, memory leaks, resource leaks, deadlocks, and all manner of ...


2

Does laziness within an application naturally yield a greater chance of race conditions? Of course it does. Properly written multithreaded code will not have race conditions, of course; race conditions are caused by not thinking about all the possible outcomes of ordering between multiple threads. This is not to say, however, that lazy loading directly ...


0

I wouldn't use CountDownLatch in your scenario because it's not reusable. Look at Semaphore or Cyclic Barrier for similar functionality.


2

There are two main types of multitasking: Cooperative - where code explicitly calls a function to say "do something else now" Pre-emptive - where the threading system automatically stops one thread to allow another to run These days, most multitasking code is pre-emptive, although event driven code (e.g. Twisted) is cooperative. I do remember using ...


0

A void pointer says nothing about what it is pointing to - it's a "pointer to anything". So info -> simTime is not meaningful to the compiler. You need to cast the pointer back to the correct type before dereferencing it. If you know that it will always be a shiftInfo, then try something like ((shiftInfo *) info) -> simTime. Your second warning is ...


1

struct shiftInfo *Q = malloc(sizeof(struct shiftInfo) + (maxCust*sizeof(int))); This allocates a struct shiftInfo object with space reserved for maxCust integers. Looks ok ... struct shiftInfo info; info.simTime = atoi(argv[1]); info.arrivalRate = atof(argv[2]); info.tellers = atoi(argv[3]); info.serviceTime = atoi(argv[4]); info.sampleInterval = ...


2

There are two elements to this problem: #1, the technical change to the existing code base to support multi-threading, and #2 changing the culture of the company in order to be aware of thread safety in the code. The first is relatively simple. First, document the functions in the class that are thread safe and are not thread safe. I agree with Jeffery ...


2

Adding multi-threading is a major new feature of a class. I think you should treat it like a major new feature, and don't try to sneak it in. Rethink and refactor the class and it relationships. I would look into creating a new class to represent each threaded task and/or slice of functionality. If needed you can preserve the old class interface as a proxy ...


4

Wrap all access to the variables in a thread safe function so that access of the variables from anywhere in the code flows through a single method, and make the variable private. This way any access of the variable from outside the class will be thread safe. The next step is to move the variables into their own class, only accessible via the safe methods. ...



Top 50 recent answers are included