Ive begun to learn about threading and semaphores in class and my teacher asked us an interesting question. Why do semaphores not have any getter methods. I thought about it and found no reasons for why this might be and couldn’t find anything online. Is there a good reason for this?
Related
I've recently learned that "Agility doesn't imply thread safety." Can anyone explain how the two differ, and why one doesn't imply the other? I'm particularly interested in learning about this in the context of C++ COM pointers, if that's at all relevant. Thank you for any info.
I wish to learn about the diagrams mentioned in the title but on the internet one can find a lot of trash, I have seen some that contradict each other.
Hence I wish someone experienced if they could spare a minute to direct me to reliable sources to learn the above mentioned.
uml-diagrams.org presents examples of what you are looking for.
I'm currently revising for an exam and came across this question:
Under what circumstances is a spinlock a suitable implementation for a
lock? When would it be a bad choice of implementation? Describe a
better solution and write a pseudo-code definition for it.
I can answer the question about the un/suitability of spinlocks, but I am absolutely stumped what constitutes a "better solution" and how to implement that in pseudo-code. I'd appreciate if someone could point me in the right direction.
I would do some investigation into topics like "Critical Section", "Mutex", "Semaphore", "I/O Completion Ports" and think about mechanisms for posting waiting threads.
I'm looking for a good slideshow/pdf/video explaining the differences in approach and thinking from hand-written threading of applications compared to the more abstracted and easier to use message passing and actor models. Does anyone know of existing resources to explain these concepts with good diagrams and visualizations?
It is slightly difficult to make direct comparisons without long, painful digressions, or a largely theoretical discussion. However, the following can be easily read, and I believe that the comparisons will form naturally for anyone familiar with the threading model.
Google's language GO uses message passing among co-routines as a core part of its concurrency model. There is a lot more information on GO at golang.org, and the following URL provides information about their concurrency model in GO.
http://golang.org/doc/effective_go.html#concurrency
This is a paper written by Edward Lee (Berkeley EECS department chair) called The Problem with Threads. It is a pitch for the actor model, and is a good read. Also note that there are other papers by Edward that deal with the problem with threads (visit his homepage for more papers).
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
It seems difficult to design a threading package in OO class than in
functional programming.
Do you have a specific question? You have asked an extremely similar question here, and I would call this one a duplicate. You can look at the design and answers in that thread to give you an idea.
But we cannot help you until you ask a specific question.
Threading is a difficult concept. But OO languages are perfectly suitable for implementing those.
Define a thread class, that runs in its own thread. Create a subclass and override the required methods.
On the contrary, there are zillions of threading libraries for OO languages. Which specific language do you think has difficulties in this area?