Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
At some point I read that operating systems were meant to be created in a certain way (i.e. 'microkernel') to be resistant to fault but are made in another way (i.e. 'monolithic') for practical purposes such as speed. Whilst this is not the question, it does bring up the question:
Have any fundamental tradeoffs been made in computer architecture that have reduced security from the earlier theoretical systems?
I'm looking for answers that are accepted in the field of computer science, not opinions on current implementations. For example programs could run faster if they were all built on custom hardware, this is known, but this is impractical which is why we have general computers.
Anyone saying that microkernels are "the right way" is wrong. There is no "right way". There is no objectively best approach to security.
The problem is that security is not fundamental to computing. It's a sociological issue in a lot of ways, it only exists because humans exist - unlike computation, which is a literal science.
That said, there are principals of security that have held true and been incorporated into hardware and software, like the principal of least privilege. The kernel in an operating systems, on the hardware, runs at a higher privilege level than userland processes. That's why your program can't actually interact with hardware, and has to use system calls to do so.
There are also issues of complexity, and various measurements of complexity. Programs tend to get more complex as our needs grow - instead of a basic game of pong we now have 1,000 AI units on a giant map. Complexity goes up, and our ability to reason about the program will likely go down, opening up holes for vulnerabilities.
There's no real answer to your question but this - if there is an objective method for security we haven't discovered it yet.
SECURITY IS NOT A FUNCTION OF NATURE OF KERNEL.
Types of kernels has nothing to do with the security of the operating system. Though I would agree that the efficiecny of an operating system does depend on it's nature.
Monolithic kernel is a single large processes running entirely in a single address space. It is a single static binary file. Whereas, in Microkernels, the kernel is broken down into separate processes, known as servers. Some of the servers run in kernel space and some run in user-space. All servers are kept separate and run in different address spaces.The communication in microkernels is done via message passing.
Developers seem to prefer micro-kernels where as it provides flexibility and also it is more easy to work with different userspaces. Monolithic is somewhat complex in it's nature and is beneficial for lightweight systems.
Is their some fundamentally flawed way our computers are structured
that allow all the security holes that are found? What I mean by this,
is that there are sometimes the proper theoretical ways to do things
in computer science that satisfy all our requirements and are robust,
etc, .
Their are certain concepts like protection-ring and capability based security and all,but, at the end this depends on the requirements of the system. For more clarity be sure to visit the links provided. SOmewhat minor ideas are highlighted below.
Capability-based_security :- Although most operating systems implement a facility which resembles capabilities, they typically do not provide enough support to allow for the exchange of capabilities among possibly mutually untrusting entities to be the primary means of granting and distributing access rights throughout the system.
Protection_ring :- Computer operating systems provide different levels of access to resources. A protection ring is one of two or more hierarchical levels or layers of privilege within the architecture of a computer system. This is generally hardware-enforced by some CPU architectures that provide different CPU modes at the hardware or microcode level. Rings are arranged in a hierarchy from most privileged (most trusted, usually numbered zero) to least privileged (least trusted, usually with the highest ring number).
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I'm actually working as a Developper on the mainframe field. Reading many documentations I understand that the real power of such systems is that they can treat many transactions (input/output) operation at the same time. They're also needed to keep high performances.
So I was wondering, aren't the modern systems capable of performing the same or even better?
To correct some mis-understandings.
Mainframe hardware is not "old" -- it has had continuous development
and undergone a refresh cycle every two or three years. The chippery involved
is in some ways more advanced than x86 -- things like have a spare cpu on each
chip -- most of the differences are aimed at reliability and availability rather
than raw performance.
Having said that both manufacturers are moving the same electrons around on the same silicon so actual per CPU performance is much the same.
Likewise mainframe software comes in two varieties "ancient" and "modern".
Some software like "CICS" was first developed in the 1970s and although it
is actively maintained it still has some of the original code.
Some software (IEBCOPY we are looking at you) was developed in the 1960s and was considered terrible even then has been left untouched for decades.
However zOS also runs a fully POSIX compliant UNIX shell in which you can run any compliant J2EE application or compile any C/C++ program to run in.
While a well set up x86 environment can match the raw processing power, they fall slightly behind when it comes to reliability and availability.
The main reason why so many large corporations stick with the mainframe is the large body of bespoke software written for COBOL/CICS, PL/1-IMS environments at a
time when hardware was expensive and coding efficiency was at a premium.
So you could re-write an old COBOL/CICS application in Java/J2EE, but, you
would need about five times the raw processing power for the new system,
always assuming you could work out what business rules and logic was
embedded in the older system.
There are many factors involved in choosing a platform. The fact is that existing mainframes (generally IBM z/OS systems is what is implied) have a massive amount of existing programs, business processes, disaster recovery plans, etc. that would all need to be refactored. Your talking about migrating existing applications based on runtimes that do not exist on other platforms. Not to mention that massive amount of data that exists both transactionally and historically.
For instance, Customer Interactive Control System (CICS) uses a specific API called CICS EXEC where program calls, database interactions, internal programming facilities like queues exist. All of these programs need to be re-written, ported and established by moving the programs, processes and data to new platforms. Its rewriting 50 years of a business' investment.
This is inherently risky to a business. You are disrupting existing operations and intellectual property and data to gain what? The cost of any such move is massive and risky for what benefit? It ends up being risk / reward.
Bear in mind, that there is a new legacy built on Windows and Linux that will likely be "disrupted" in the future and its not likely that one would move all those applications for the same reasons.
As #james pointed out, mainframes are close to, if not currently, the fastest single general computing platforms out there. New hardware versions come out every two years and software is always being added to the platform, Java, Node, etc. The platform continues to evolve.
Its a complicated subject and not as simple as "use other technology" to perform the same or better. Its moving the programs, data and processes, which is really the hard part.
"performing better" is highly unlikely because the mainframe segment is still highly relevant in business and its architectures are kept closely up-to-date with all evolutions both in hardware and [system] software.
"performing the same" is theoretically certainly possible, but it must be noted that some of the more popular mainframe architectures have significantly different hardware setups, e.g. the processors in z/OS systems are, comparatively, pathetically slow, but they delegate lots and lots of work to coprocessors, and it must also be noted that on the software side, mainframers tend to have a higher degree of "resource-awareness" than, eurhm, more "modern" developers.
That said, of course any answers to this question will necessarily be more opinion than hard-facts based, which makes it an unfortunate thing to ask here.
I'm curious about differences between distributed and multi-agent systems. I have seen many fundemental similarities and my mind is confused.
Similarities:
1- there are multiple processing units
2- both are used for computing and simulation applications
3- processing units interacting
4- processing units work collectively and become powerfull machine
5- units work with their own properties like own specific clock, own specific processor speed, own memory etc..
So what is the difference(s)?
It is a matter of abstraction and purpose. Multi-agent systems employ powerful high-level abstractions, based on complex (i.e. intelligent) components, which are usually not found in regular distributed system created only to split simple number crunching algorithms over different machines. Multi-agent systems can be used to solve problems that are difficult or impossible for an individual agent or a monolithic system to solve. Distributed computing can be used to solve problems that are embarrassingly parallel. Sure, there are similarities, but if you look close at their abstractions, they can profoundly contrast, leveraging from different algorithms and data structures.
In my perspective the key is the definition of (intelligent) agent. S. Russel and P. Norvig in their "Artificial Intelligence: A Modern approach" defined:
An agent is anything that can be viewed as perceiving is environment through sensors and acting upon that environment through actuators.
So a multi-agent system will be formed by a collection of agents that perceive the environment and and act upon it but remain in some degree independent and decentralized, with a local view to the environment.
A distributed system is (usually) defined as a collection of nodes performing distributed calculations, linked together to multiply processing power.
In a way a MAS is a distributed system, but has some characteristics that make it unique. It depends on the usage and the particular implementation of the system but in some way those definitions overlap a bit.
The question is a bit old but I will still take a shot at it.
We can start by looking at definitions.
Distributed system [1]:
We define a distributed system as one in which hardware or software components located at networked computers communicate and coordinate their actions only by passing messages. This simple definition covers the entire range of systems in which networked computers can usefully be deployed.
Multiagent system [2]:
Multiagent systems are those systems that include multiple autonomous entities with either diverging information or diverging interests, or both.
So, fundamentally, "Distributed" is concerned with the architecture of a system while "Multiagent" is concerned with a specific method of problem solving employed in a system.
By virtue of being distributed, a system is made up of several networked computers. A multiagent system, on the other hand, can exist in a networked environment or on a single non-networked computer.
References
[1] G. Couloris, J. Dollimore, T. Kindberg, G. Blair, Distributed Systems Concepts and Design (Fifth Edition), 2012, Addison-Wesley.
[2] Y. Shoham, K. Leyton-Brown, Multiagent Systems: Algorithmic Game-Theoretic and Logical Foundations (Revision 1.1), 2010, Cambridge Univ. Press.
When I think about Distributed Computing, load is distributed to multi parts, be it multi-thread or multi-computers. In the distributed computing, every part is parallel, that is they are almost the same. Some last computing parts that collects and summarizes results of others may be different than others.
Multi Agent Systems as its name implies has multiple agents that work together to accomplish a goal. Different than Distributed Computing, a multi agent system may work on single computer but it will certainly have more than one agent. These agents may be collector agent, reporter agent, computing agent, ....
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I understand that the answer to this question, like most, is "it depends", but what I am looking for is not so much an answer as much as a rationale for the different things affecting the decision.
My use case is that I have an ARM Cortex A8 (TI AM335x) running an embedded device. My options are to use some embedded linux to take advantage of some prebuilt drivers and other things to make development faster, but my biggest concern for this project is the speed of the device. Memory and disk space are not much of a concern. I think it is a safe assumption that programming directly against the mpu and not using a full OS would certainly make the application faster, but gaining a 1 or 2 percent speedup is not worth the extra development time.
I imagine that the largest slowdowns are going to come from the kernel context switching and memory mapping but I do not have the knowledge to correctly assess or gauge the extent of those slowdowns. Any guidance would be greatly appreciated!
Your concerns are reasonable. Going bare metal can/will improve performance but it may only be a few percent improvement..."it depends".
Going bare metal for something that has fully functional drivers in linux but no fully functional drivers bare metal, will cost you development and possibly maintenance time, is it worth that to get the performance gain?
You have to ask yourself as well am I using the right platform, and/or am I using the right approach for whatever it is you want to do on that processor that you think or know is too slow. Are you sure you know where the bottleneck is? Are you sure your optimization is in the right place?
You have not provided any info that would give us a gut feel, so you have to go on your gut feel as to what path to take. A different embedded platform (pros and cons), bare metal or operating system. Linux or rtos or other. One programming language vs another, one peripheral vs another, and so on and so on. You wont actually know until you try each of these paths, but that can be and likely is cost and time prohibitive...
As far as the generic title question of os vs bare metal, the answer is "it depends". The differences can swing widely, from almost the same to hundreds to thousands of times faster on bare metal. But for any particular application/task/algorithm...it depends.
Long put short: The teacher who taught me through out the last year has only recently left and has been replaced with a new one. This new teacher has given me an assignment that involves things (like this) that we were never previously taught. So this task has showed up on the assignment and I have no idea how to do it. I can't get hold of the teacher because he's poorly and not coming in for the next few days. And even when I do ask him to explain further, he gets into a right mood and makes me feel like I'm completely retarded.
Describe how the hardware platform impacts upon the choice for
the programming language
Looking at my activity here on SO, you can tell that I'm into programming, I'm into developing things, and I'm into learning, so I'm not just trying to get one of you guys to do my homework for me.
Could someone here please explain how I would answer a question like this.
Some considerations below, but not a full answer by any means.
If your hardware platform is a small embedded device of some kind, then your choice of programming language is going to be directed towards the lower level unmanaged languages - you probably won't be able to (or want to) load a managed language runtime like the Java JVM or .NET CLR. This is down to memory and storage requirements. Similarly, interpreted languages will be out of the question as you won't have space for the intepreter.
If you're on a larger machine, it's more a question of compatibility. A managed language must run on a platform where its runtime is supported. In the case of .NET, that's Windows, or other platforms if you substitute the Microsoft CLR with the Mono runtime. In the case of Java, that's a far wider range of platforms.
This is by no means a definitive answer, but my first thought would be embedded systems. A task I perform on an embedded system, or other low powered battery operated computer, would need to be handled completely different to that performed on a computer which has access to mains electricity.
One simple impact.. would be battery life.
If I use wasteful algorithms on an embedded system, the battery life will be affected.
Hope that helps stir the brain juices!
Clearly, the speed and amount of memory of the device will impact the choice. The more primitive and weak the platform is, the harder it is to run code developed with very high level languages. Code written with them may just not work at all (e.g. when there isn't enough memory) or be too slow or it will require serious optimizations (i.e. incur more work), perhaps affecting negatively the feature set or quality.
Also, some languages and software may rely heavily on or benefit from the availability of page translation in the CPU. If the CPU doesn't have it, certain checks will have to be done in software instead of being done automatically in hardware, and that will affect the performance or the language/software choice.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
We have a codebase that is several years old, and all the original developers are long gone. It uses many, many threads, but with no apparent design or common architectural principles. Every developer had his own style of multithreaded programming, so some threads communicate with one another using queues, some lock data with mutexes, some lock with semaphores, some use operating-system IPC mechanisms for intra-process communications. There is no design documentation, and comments are sparse. It's a mess, and it seems that whenever we try to refactor the code or add new functionality, we introduce deadlocks or other problems.
So, does anyone know of any tools or techniques that would help to analyze and document all the interactions between threads? FWIW, the codebase is C++ on Linux, but I'd be interested to hear about tools for other environments.
Update
I appreciate the responses received so far, but I was hoping for something more sophisticated or systematic than advice that is essentially "add log messages, figure out what's going on, and fix it." There are lots of tools out there for analyzing and documenting control-flow in single-threaded programs; is there nothing available for multi-threaded programs?
See also Debugging multithreaded applications
Invest in a copy of Intel's VTune and its thread profiling tools. It will give you both a system and a source level view of the thread behaviour. It's certainly not going to autodocument the thing for you, but should be a real help in at least visualising what is happening in different circumstances.
I think there is a trial version that you can download, so may be worth giving that a go. I've only used the Windows version, but looking at the VTune webpage it also has a Linux version.
As a starting point, I'd be tempted to add tracing log messages at strategic points within your application. This will allow you to analyse how your threads are interacting with no danger that the act of observing the threads will change their behaviour (as could be the case with step-by-step debugging).
My experience is with the .NET platform and my favoured logging tool would be log4net since it's free, has extensive configuration options and, if you're sensible in how you implement your logging, it won't noticeably hinder your application's performance. Alternatively, there is .NET's built in Debug (or Trace) class in the System.Diagnostics namespace.
I'd focus on the shared memory locks first (the mutexes and semaphores) as they are most likely to cause issues. Look at which state is being protected by locks and then determine which state is under the protection of several locks. This will give you a sense of potential conflicts. Look at situations where code that holds a lock calls out to methods (don't forget virtual methods). Try to eliminate these calls where possible (by reducing the time the lock is held).
Given the list of mutexes that are held and a rough idea of the state that they protect, assign a locking order (i.e., mutex A should always be taken before mutex B). Try to enforce this in the code.
See if you can combine several locks into one if concurrency won't be adversely affected. For example, if mutex A and B seem like they might have deadlocks and an ordering scheme is not easily done, combine them to one lock initially.
It's not going to be easy but I'm for simplifying the code at the expense of concurrency to get a handle of the problem.
This a really hard problem for automated tools. You might want to look into model checking your code. Don't expect magical results: model checkers are very limited in the amount of code and the number of threads they can effectively check.
A tool that might work for you is CHESS (although it is unfortunately Windows-only). BLAST is another fairly powerful tool, but is very difficult to use and may not handle C++. Wikipedia also lists StEAM, which I haven't heard of before, but sounds like it might work for you:
StEAM is a model checker for C++. It detects deadlocks, segmentation faults, out of range variables and non-terminating loops.
Alternatively, it would probably help a lot to try to converge the code towards a small number of well-defined (and, preferably, high-level) synchronization schemes. Mixing locks, semaphores, and monitors in the same code base is asking for trouble.
One thing to keep in mind with using log4net or similar tool is that they change the timing of the application and can often hide the underlying race conditions. We had some poorly written code to debug and introduced logging and this actually removed race conditions and deadlocks (or greatly reduced their frequency).
In Java, you have choices like FindBugs (for static bytecode analysis) to find certain kinds of inconsistent synchronization, or the many dynamic thread analyzers from companies like Coverity, JProbe, OptimizeIt, etc.
Can't UML help you here ?
If you reverse-engineer your codebase into UML, then you should be able to draw class diagrams that shows the relationships between your classes. Starting from the classes whose methods are the thread entry points, you could see which thread uses which class. Based on my experience with Rational Rose, this could be achieved using drag-and-drop ; if no relationship between the added class and the previous ones, then the added class is not directly used by the thread that started with the method you began the diagram with. This should gives you hints towards the role of each threads.
This will also show the "data objects" that are shared and the objects that are thread-specific.
If you draw a big class diagram and remove all the "data objects", then you should be able to layout that diagram as clouds, each clouds being a thread - or a group of threads, unless the coupling and cohesion of the code base is awful.
This will only gives you one portion of the puzzle, but it could be helpful ; I just hope your codebase is not too muddy or too "procedural", in which case ...