Bowsy.com

bowsycom

The Adventures of Sherlock Holmes: Chapter IV - The Boscombe Valley Mystery

184 Stories To Learn About Psychology

Let's learn about via these 41 free stories. They are ordered by most time reading created on HackerNoon. Visit the to find the most read stories about any technology. Ideas /Learn Repo 1. Time is NOT Money! Time is NOT Money…Time is truly scarce and the only currency that really matters. 2. Looking for Micro SaaS Ideas? Here Are 7 You Could Build In 2023 Here's a list of Micro SaaS ideas that you could use as inspiration when coming up with your own Micro SaaS app project to work on. 3. It All Begins With a Side Project Growing up building 4. How to Generate New Software Startup Ideas Ideas are responsible for the progression and prosperity of humans, without them we would still be living in prehistoric times. People spend most of the day work, smartphones when we’re out and about, and tablets and PCs at home. Congratulations to the thousands of software companies that have already helped to make history. Numerous software ideas have been made for people to choose the one with benefits to them. 5. Forget What You See on TV: Good Ideas Don’t Come From Brainstorming The reality of brainstorming sessions is far from the idealized scenes made to entertain us. 6. An Effective Way To Write Executive Summaries For Your Concepts This article describes the ‘idea model’ and provides various examples of real ideas — explains how to write effective executive summaries for your concepts. 7. Detecting Fake Viral Stories Before They Become Viral Using FB API This is the first part of a X part article. 8. 10 Ideas To Make You A Better Product Manager Today, there are so many ways to learn how to be a better product manager. There are books, courses and articles which will teach you the various skills and techniques you need to know. But in this article, I don't want to talk about these. Instead, I want to share some ideas from other disciplines, like economics, psychology and manufacturing that changed the way I think and made me a better product manager. I hope they spark interest and do the same for you! 9. Todays 5 Ideas: 31.08.2020 A text editor where Pac-Man will start eating the text whenever you press backspace. 10. Can’t Buy Me Love: An Argument for Implementing Illiquidity Mapping human values into code.  Hint: its hard to measure them in bitcoin. 11. How I Prove My Ideas Before Implementing Them Time is the most valuable asset, use it wisely. That is why you should  prove your ideas before implementing them. Programming is time consuming, I love programming but I avoid writing code whenever it is possible. A perfect written software, that nobody wants, is just a waste. To identify if an idea worth implementing, I use these tactics. 12. When Burning Man Gets Boring, Silicon Valley Should Worry Burning Man 2002. Photo: Phil Gyford 13. How To Easily Validate Startup Ideas The first step in building a startup is validating the idea. It is a huge risk building a product without know if there are demand for it. The easiest and cheapest way to validate a start up idea is always cold email people at first. 14. We Need Tech to Augment Short-Term Memory for Decision-Making and Relationships We live in an age of information overload, among always-on social networks, real time notifications, on-demand video, live streaming and attention-grabbing viral loops of content online. And because attention means advertising dollars, companies are driven to optimize themselves by exploiting hooks to drive usage, such as those that target our dopamine receptors. 15. How to Make Explanatory Videos for Your SaaS Product in Just 16 Hours For an explanatory video, there are multiple options. Easiest is to sit in front of your camera and speak or record your screen with voiceover. 16. The Adventures of Sherlock Holmes - TABLE OF LINKS The Adventures of Sherlock Holmes, by Sir Arthur Conan Doyle is part of HackerNoon’s Book Blog Post series. 17. Todays 5 Ideas: 29.08.2020 A recycling bin that compresses my trash allowing me more space to fill. 18. The Feedback Fairy 🧚‍♀️ Shouldn't feedback be one of the easiest things we do as designers or developers? Just look at Who Wants to Be A Millionaire. When you get stuck, just phone-a-friend and make a million dollars. Easy right? 19. Let's Build a New Social Network to Keep Politicians Accountable? We hear lots of promises during elections from our politicians. The problem is how to track the progress of given promises? 20. How to Get Started with Writing Online Here’s what you need to know about the writing process to get you started with writing online. 21. 10 Features We Could Build to Improve Online Meeting & Collaboration Tools Video conferencing tools like Zoom, Skype, or WebEx along with Digital tools like Microsoft Teams and Slack are deeply embedded into the modern ways of working — even more during the lock-down era. And their role will only get more important. 22. The Adventures of Sherlock Holmes: Chapter I - A Scandal in Bohemia The Adventures of Sherlock Holmes, by Arthur Conan Doyle is part of HackerNoon’s Book Blog Post series. You can jump to any chapter in this book here: Table of 23. From App Idea To Implementation [Guideline] When you have an app idea, you need to get things sorted out before you jump onto the development train. Getting the right people at the table, talking to users and defining your blueprint will help you to get things sorted out. Read on if you want to get solid advice on doing so. 24. How to Test Your Startup Idea In this post, I’d like to share my learnings on how to validate product ideas quickly. This is an extremely useful skill to have when building 0 to 1 products, because most product ideas will fail in the market. So, better not spend 3-6 months building something that nobody wants. Note that idea validation is different from problem validation. Problem validation requires following a different playbook. 25. Creativity and Problem Solving is Required at Every Level Many times, the best problem solvers in an organization never get a chance to contribute their creativity, so a lot of potential goes undiscovered. 26. Diversity is Great. But, Is Niche Really The Future of E-Commerce? Generic markets typically contain groups of consumers that share a broad need which can be met by a wide variety of products or services. In the past two years, Facebook has been struggling to stay relevant and has reported a first-time decline in monthly user growth in the last quarter, where as Instagram and LinkedIn have been galloping at a pace of 2x and 5x respectively. 27. Explore What it Means to Build Online Communities in the Age of Web3 Since the dawn of the internet, people have found groups they can connect and share similar interests. 28. Selling Your Million-Dollar Idea to Management The relevance and priority of a new idea to management depends heavily on how you package it. Here is a step-by-step guide to get them excited about your idea. 29. 10 Startup Ideas Spun Off Product Hunt's Business Model This time I have prepared a bunch of ideas (more ideas - less data) based on the same or similar business model as Product Hunt. Next week you will receive one idea that is bouncing in my head for you but I have to make more research on it, so stay tuned…. 30. 5 Low-Investment Business Ideas You Can Start Online Entrepreneurship definitely is one of the most misconceived terminologies of the era. It seems like a mountain of tasks to start a business. When we think of all the time, money, and risks involved, it’ just seems so inaccessible to a regular man or woman. 31. Learn Idea Generation Using SCAMPER You need not be a natural at coming up with innovations; Use SCAMPER to generate ideas and innovate your product, service, business. 32. The Hound of the Baskervilles: Chapter 1 - Mr. Sherlock Holmes The Hound of the Baskervilles, Chapter 1 by Arthur Conan Doyle is part of HackerNoon’s Book Blog Post series. 33. Conquering Imposter Syndrome for Success Conquer Imposter Syndrome for Unbelievable Success 34. Notes from Startup School Week 1 Videos For people who are busy. 35. Reanimating the forgotten skill of brainstorming: 4 ways to brainstorm remotely + bonus tips This post tries to resurrect brainstorming and suggest new ways to brainstorm remotely with bonus tips relevant in a tech-driven and remote work setting. 36. Find The Right Sponsor for Your Open Source Project The ongoing maintenance and growth of open source projects are clearly in the best interest of the software companies using them. And yet, raising money for an open-source project is difficult, and many developers struggle with finding the right sponsors for their projects. What is the best way to get the resources open source developers need to keep developing? 37. How and Why Makers Should Set a Deadline They Can't Extend Hi, makers:) 38. The Adventures of Sherlock Holmes: Chapter III - A Case of Identity The Adventures of Sherlock Holmes, by Arthur Conan Doyle is part of HackerNoon’s Book Blog Post series. 39. The Adventures of Sherlock Holmes: Chapter V - The Five Orange Pips The Adventures of Sherlock Holmes, by Arthur Conan Doyle is part of HackerNoon’s Book Blog Post series. 40. The Adventures of Sherlock Holmes: Chapter IV - The Boscombe Valley Mystery The Adventures of Sherlock Holmes, by Arthur Conan Doyle is part of HackerNoon’s Book Blog Post series. 41. The Adventures of Sherlock Holmes: Chapter VIII- The Adventure of the Speckled Band The Adventures of Sherlock Holmes, by Arthur Conan Doyle is part of HackerNoon’s Book Blog Post series. Thank you for checking out the 41 most read stories about Ideas on HackerNoon. to find the most read stories about any technology. Visit the /Learn Repo

41 Stories To Learn About Ideas

In the ever-evolving world of technology, new buzzwords, and terminologies frequently emerge as marketing ploys designed to catch the attention of potential consumers. As cybersecurity professionals, it's crucial for us to look beyond the hype and understand the core concepts of these terms. In this HackerNoon long read, we will delve deep into the differences and similarities between Web Security and API Security, comparing the OWASP Top Ten 2021 and OWASP API Top Security Ten 2019 to shed light on the rationale behind the split. We will conclude by highlighting how legacy web apps are essentially legacy APIs, emphasizing that securing them is fundamentally the same process. The Rationale Behind the Split, or IDOR/BOLA Tweens Despite the overlap, there is still a rationale behind the split between web and API security. The key difference lies in the way web applications and APIs are designed, developed, and consumed. Web applications typically rely on user interfaces (UI) and serve content directly to end-users. APIs, on the other hand, act as intermediaries between different software applications, allowing them to communicate and share data. APIs are becoming increasingly crucial in modern software development, especially with the rise of microservices and cloud-based architectures. The unique nature of APIs means that they face specific security challenges that might not be as relevant in traditional web applications. For example, broken object-level authorization (BOLA) is a more significant concern in APIs than in web applications, where insecure direct object references (IDOR) are the more common vulnerability. The distinction between BOLA and IDOR lies in the fact that BOLA specifically targets APIs, while IDOR focuses on web applications. However, these two issues are exactly the same from a technical standpoint. Classic Web Injections vs API Injection To better understand the differences between Web Security and API Security, let's take a closer look at two common injection vulnerabilities: SQL Injection for Web Applications and Object Injection for APIs. These examples will demonstrate the unique challenges faced by each and provide valuable insights into their respective security requirements. SQL Injection is a well-known vulnerability in web applications that occurs when an attacker is able to insert malicious SQL code into a query, which is then executed by the database management system. This can result in unauthorized access to sensitive data, modification of data, or even complete control over the affected database. Here's a simple example of vulnerable code: codedef get_user_data(user_id):
    query = f"SELECT * FROM users WHERE id = {user_id}"
    result = execute_query(query)
    return result In this example, the user-supplied is directly embedded into the SQL query, making it vulnerable to SQL injection attacks. An attacker could provide a malicious such as , which would result in the query returning all user records. user_id user_id 1 OR 1=1 On the other hand, Object Injection is a vulnerability specific to APIs that occurs when an attacker is able to manipulate serialized objects or data structures within an API request, leading to unauthorized access, data manipulation, or even remote code execution. Here's a simple example of vulnerable code: codeconst express = require('express');
const app = express();
const bodyParser = require('body-parser');
app.use(bodyParser.json());

app.post('/api/users', (req, res) => {
    const userData = req.body;
    const newUser = new User(userData);
    newUser.save()
        .then(result => res.status(201).send(result))
        .catch(err => res.status(400).send(err));
}); In this example, the API endpoint accepts a JSON payload representing a new user object. However, it does not properly validate or sanitize the input, allowing an attacker to potentially manipulate the object structure, inject malicious data, or even execute arbitrary code on the server. For instance, an attacker could submit a payload containing a malicious operator in a MongoDB application, leading to the execution of arbitrary JavaScript code on the server. $where As demonstrated by these examples, both Web Security and API Security share similar concerns in terms of injection vulnerabilities. However, the specific nature of these vulnerabilities and the ways in which they are exploited differ due to the unique characteristics of web applications and APIs. As a result, it is essential for developers and security professionals to understand these differences and tailor their security measures accordingly. By doing so, they can better protect their applications and APIs from a wide range of threats and vulnerabilities, ensuring a more secure and robust software ecosystem. Web XSS vs XSS for API Cross-Site Scripting (XSS) is a security issue that shows the differences between Web Security and API Security. XSS happens when a bad actor puts harmful scripts into a web app, which the victim's browser then runs. In web apps, XSS attacks are really dangerous because they can lead to stealing sessions, taking data, or damaging the affected site. Here's a basic example of unsafe code in a web app: 
<form action="/submit_comment" method="post">
    <input type="text" name="comment" />
    <input type="submit" value="Submit" />
</form>


<div>
    <%= user_comment %>
</div> In this case, user input, like a comment, isn't cleaned up before being put into the page's HTML. A bad actor could send a comment with harmful JavaScript code, like , which would then run on the browser of anyone looking at the comment. <script>alert('XSS')</script> For APIs, XSS attacks usually aren't as big of a deal since APIs don't usually give HTML content right to users. But, XSS issues can still matter for APIs using cookie-based authentication. A bad actor could use an XSS weakness in a web app to steal the user's authentication cookie and wrongly access the API. Check out this example: // API endpoint using cookie-based authentication
app.post('/api/comments', (req, res) => {
    const comment = req.body.comment;
    const user_id = req.cookies.user_id;
    
    // Check user_id from the cookie for authentication and authorization
    // ...

    // Save the comment without proper input sanitization
    saveComment(user_id, comment)
        .then(() => res.status(201).send())
        .catch(err => res.status(400).send(err));
}); In this situation, if the web app with the API has an XSS issue, a bad actor could use the XSS weakness to get the user's authentication cookie and make API calls they shouldn't. This shows how important it is to make sure both the web app and API are safe because a problem in one could hurt the security of the other. So, while XSS issues are more common in web apps, they can still affect API security, especially when using cookie-based authentication. Developers and security pros need to know about these risks and use best practices like checking input, encoding output, and using safe coding methods to reduce the chance of XSS attacks on both web apps and APIs. One challenge in protecting APIs from XSS attacks is that Web Application Firewalls (WAFs) are often designed to block web XSS only. These firewalls might not be as effective at blocking API XSS, which can lead to security gaps. To address this, developers should consider using API-specific security tools and techniques in addition to traditional web security measures. Conclusion As we've seen, both web applications and APIs face unique security challenges, but they also share some common vulnerabilities. Relying solely on Web Application Firewalls (WAFs) for security might not be enough, as they are often designed to protect web apps from XSS attacks but may fall short when it comes to API security. To better safeguard your web applications and APIs, it's important to consider using an API security solution in addition to traditional web security measures. Not all modern API security tools can easily replace WAFs, but some of them offer a comprehensive approach by combining Web Application and API Protection (WAAP) with their Advanced API Security Solution. This enables you to enjoy robust security coverage for both your web apps and APIs. By staying informed about the latest security best practices and using the right tools, like Wallarm, you can ensure that your web applications and APIs are well-protected against the ever-evolving landscape of cyber threats.

Unraveling Web and API Security by Vulnerabilities Examples

Building Websites Using Templates vs. Developing From Scratch

How to Get Your SaaS Product to No.1 on AppSumo

The Ultimate AHREFs Guide: Keyword Research and Beating Your Competition

How to Build a Job Application Tracking System with Notion API, Node.js, and FastifyJS

In our , we introduced sequential consistency, the threading programming contract between programmers and computer systems. last installment We are about to dive further into the most common memory consistency model in practice, . The beauty of this consistency is that while it's much cheaper for systems to implement, given proper locking however, we can formally prove that it is equivalent to sequential consistency. release consistency After finishing this article, C++'s documentation will actually look like English to you. You will also feel more at ease navigating the water crafting your own synchronization methods, without resorting to off-the-shelf solutions such as library-provided locks. std::memory_order But first, it's necessary to make a detour to get acquainted with the staple of multi-thread programming: locks, which is so essential to 's intuition and implementation. release consistency Locks Use case In our last episode, we covered an example in which two threads race to update two variables and . Let's reuse it as our in this article: i j example1 i = ; j = ; output[ ]; {
  i = ;
  output[ ] = j;
} {
  j = ;
  output[ ] = i;
} int 0 int 0 int 2 void func0 () 1 1 void func1 () 1 0 Honestly, this was only a contrived example perfectly fit for demonstrating broken memory consistencies. The most common synchronization need actually arises from the necessity of grouping multiple memory operations in one shot. This need was as old as the concept of multithreading. It even predates SMP or consistency model. Let's look at a more realistic . example2 id = ; my_id[ ]; { my_id[ ] = id++; } { my_id[ ] = id++; } int 0 int 2 void func0 () 0 void func1 () 1 Here we have two threads wanting to generate their own unique IDs. The hazard here is that the innocent increment is actually two memory operations slammed together. It's commonly referred to as . If we paste this snippet into , we can show that on x86 each function roughly takes 4 instructions -- read-add-write for and the assigning the value to : id++ read-modify-write compiler explorer id++ my_id func0():                              # @func0()
        movl    id(%rip), %eax
        leal (%rax), %ecx
        movl    %ecx, id(%rip)
        movl    %eax, my_id(%rip)
        retq 1 Of course, we're not counting the function return as a proper instruction here. The race condition is evident. If both threads will do the reads first before the other completes the whole read-modify-write sequence, it'll be possible for both threads to get an ID of 0. We can also write a full program that produces this result: id = ; my_id[ ]; { my_id[ ] = id++; } { my_id[ ] = id++; } {
  id = ; :: ; :: ;

  t0.join();
  t1.join(); :: << my_id[ ] << my_id[ ] << :: ;
} { (;;) {
    run_test();
  } ;
} # include <iostream> # include <thread> int 0 int 2 void func0 () 0 void func1 () 1 void run_test () 0 std thread t0 (func0) std thread t1 (func1) std cout 0 1 std endl int main () for return 0 Do you see that we're fundamentally dealing with a different issue that here? can break because instructions can be reordered, and here we break because instructions may be interleaved, even when they are completely executed in program order! example1 Example 1 One way to solve the problem is to wrap in an construct and convert the increment to its API, which just generates a special hardware atomic instruction that takes care of the read-modify-write business. But that's just a shortcut. Prior to the C++11 standard, we would have just put the read-modify-write sequence of in a good old critical section, protected by locks, so that the access to it will be mutually excluded. id std::atomic fetch_add id Spinlock implementation How are locks implemented though? It turns out, the locking is just a read-modify-write on its own. Let's take a look at the most simple kind of lock -- spinlock. Here we can have a simplistic working implementation using C++'s . In the old days, we would have embedded assembly ourselves. std::atomic : { (;;) { expected_val = ; (busy.compare_exchange_strong(expected_val, )) ;
    }
  } { busy.store( ); } : ::atomic< > busy = ;
}; { class spinlock public void lock () for bool false if true return void unlock () false private std bool false It's called spinlock because the acquisition keeps spinning on the lock state hoping it won't be busy the next moment without ever blocking. A spinlock state could be as little as 1 bit. shows that acquiring the lock generates a (standing for compare-and-exchange) instruction: Compiler explorer cmpxchg main:                                   # @main
        movb    $ , (%rsp)
        movb    $ , %cl
.LBB0_1:                                # =>This Inner Loop Header: Depth= xorl    %eax, %eax
        lock            cmpxchgb        %cl, (%rsp)
        jne     .LBB0_1
        movb    $ , (%rsp)
        xorl    %eax, %eax
        retq 0 -8 1 1 -8 0 -8 This instruction does the following: 1) it reads out the lock state, 2) compares to the expected "not busy" value, and 3) if equal, writes the "busy" value back to the lock state. The operation can succeed or fail, and if it fails we'll just keep retrying till we actually acquire the lock. But either way, the 3 things are done together without interruption. Again, read, update, and write: The lock release doesn't have to be retried, and we unconditionally write a "not busy" value to the lock state. Note here you can pretend we have sequential consistency here. For now, you will have to trust me that the lock code will work in both uniprocessor and multiprocessor environments. After finishing the article you will see why. Now let's protect the variable using our spinlock, and both our IDs should be unique. id #include <atomic>
#include <iostream>
#include <mutex>
#include <thread> {
public: lock() { (;;) {
      bool expected_val = ; (busy.compare_exchange_strong(expected_val, )) ;
    }
  } unlock() { busy.store( ); }

private:
  std::atomic<bool> busy = ;
};

spinlock m;
int id = ;
int my_id[ ]; func0() { ::lock_guard g(m);
  my_id[ ] = id++;
} func1() { ::lock_guard g(m);
  my_id[ ] = id++;
} run_test() {
  id = ;

  std::thread t0(func0);
  std::thread t1(func1);

  t0.join();
  t1.join();
  std::cout << my_id[ ] << my_id[ ] << std::endl;
}

int main() { (;;) {
    run_test();
  } ;
} class spinlock void for false if true return void false false 0 2 void std 0 void std 1 void 0 0 1 for return 0 Release consistency Finally, we have got around to the main course of this episode. Recall that sequential consistency, for the most part, requires that there's a global ordering of all memory operations. This is very hard to implement on modern processors. X is one attempt at relaxing the memory access orders, and we could see in the last episode that it will break sequential consistency if accesses to shared variables aren't properly ordered. 86 TSO People have noticed that more often than not, shared variables ARE actually protected by locks. Like we mentioned before, this habit predates multiprocessors, so it has nothing to do with coping with memory reordering. But since locks are such special memory locations, it's tempting the think that instead of enforcing memory orders everywhere, maybe we can do something clever to the locks to maintain the sequential consistency illusion, while letting the general population of the instructions slide? This is where (RC) comes in. There are two flavors of RC, RCsc and RCpc. Both are equivalent. Let's start with RCsc, which is easier to understand, but less practical to implement compared to RCpc. release consistency RCsc These points summarize RCsc: Memory accesses are categorized into a) , acquiring and releasing a lock, and b) . synchronization ops i.e. ordinary ops No local memory accesses can be reordered after a release op. No local memory accesses can be reordered before an acquire op. Synchronization ops themselves observe sequential consistency, hence the "sc" subscript in the consistency name. This is where I want to put in a thousand words to describe the mechanism. So let's throw in a picture instead. This illustrates why these points will maintain the sequential consistency illusion. Imagine we have two critical sections (CS) executing on two processors A and B, referred to as and respectively. These are shown as two boxes in the diagram above. The critical sections are protected by a single lock. Inside the CS'es there are some accesses to locations private to the processors themselves, and some accesses to shared variables. It's easy to prove that all accesses in will strictly happen before all accesses in , and this is observed globally. The most important trick is the sequential consistency ordering between the and the established in rule No. 4. That is, CS-A CS-B CS-A CS-B CS-A release CS-B acquire CS-A release < CS-B acquire where the "<" sign denotes the global happens-before relationship. From rule No. 2 and 3, any op in will finish before the . Also any op in will finish after the . So we have the following: CS-A CS-A release CS-B CS-B acquire , and Op in CS-A < CS-A release CS-B acquire < Op in CS-B Finally, transitively, any op in will globally happen before any op in . CS-A CS-B The private accesses are irrelevant here, because at any time they are done by a single processor, and the global order is defined by that processor's order, which is guaranteed to be equivalent to sequential consistency, even though some reordering might happen. Also our strong happens-before relationship have put the shared accesses into the same situation. At any time there's only one processor doing the accesses exclusively, so the order it executes will be defined as the global order. This order must be equivalent to a sequential consistency order, which is the golden rule no system dares to break so far. You can see that all is banking on, is that outside the critical sections there shouldn't be any shared access. If you do, you're on your own for defining the access ordering. This is why C++11 kind of accesses unprotected by locks or and related constructs. Going back to at the very beginning, as alternatives to using , we could potentially use a proper lock to achieve the same purpose. release consistency outlawed std::atomic example1 std::atomic RCpc We just proved that as long as data are always protected by locks, RCsc will be equivalent to sequential consistency. However, ruminating over the requirements RCsc here, you might find it very hard to implement on actual processors. It asks for 2 kinds of ordering enforcement: sequential consistency between sync ops, and a local ordering between sync and ordinary ops. Think about how you would provide that interface when you design instructions. Common architectures just give you local memory fences. For example, has a MFENCE instruction that prevents local memory operations from being ordered across that instruction. x86 Now RCpc comes along and stops us from worrying. It says sequential consistency between sync ops might be more than sufficient. We can replace it with a consistency model called , and the world will keep revolving. processor consistency assumes that each processor has its own local memory (which is a very realistic assumption, since commonly "cores" have their own private L1 cache). Processor consistency I have deliberately refrained from linking a Wikipedia definition of here. If you must look, I'd have to caution you that this is one of the rare cases Wikipedia is wrong! Look at one of its figures: processor consistency This is an example given to explain . What this says is issues a write of value to location . receives that value, and writes to the same location . observe the two writes in different orders. This is definitely not true for processor consistency, because cache coherency protocols would have prevented that. This article is getting long, so maybe we will go through cache coherency when we look at some locking performance issues. For now, this sums up the concepts very nicely. Hypothetically some of you might have extra time for some extensive reading. processor consistency Processor1 1 x Processor2 2 x Processor3 and processor4 survey paper Essentially, is only concerned about memory ordering w.r.t. a single memory location. Suppose we have a single lock, for that lock can be thought of as a series of writes to the lock, and these writes are globally ordered. Reads from different threads however, may observe them at different timings. processor consistency processor consistency To illustrate why won't be an issue in the context of release consistency, let's look at the figure above and consider a theoretical case where 3 processors, yellow, purple and green are executing a few operations. At first yellow grabs the lock using a compare-and-exchange instruction, which is 3 ops executed without interruption. Shortly, it releases the lock. processor consistency The write operations (acquire and release) are propagated to purple first. On seeing the lock released, purple seized the opportunity and acquired the lock for its own use. Meanwhile, green only sees a release from yellow, and it tries its 3-op sequence to acquire the lock too, but dictates that the acquire op has to be a failure, because it is a write op, and it has to fit into the global ordering. So no harm is done -- green can just retry in the future without jeopardizing the lock semantics. processor consistency In reality, cache coherency protocols usually makes one processor exclusively execute the read-modify-write on the lock cache line at a time. So realistically the chart will look more like this: You might think this looks awfully like , but it's not. We are only dealing with one memory location here (the lock), whereas mandates a total operation ordering, across all memory locations. sequential consistency sequential consistency In the cases where you need to acquiring multiple locks to get to the critical section, this model will guarantee correctness as well. The proof is assigned to you, the reader, as an exercise. 😀 This is great news! So as long as a processor implements as its memory consistency by default, we can safely build on top to present programmers sequential consistency, provided all shared memory accesses are protected by locks. In reality is a very reasonable thing to assume, given how cache coherency is implemented. More on that topic later. processor consistency processor consistency It might be obvious but let's spend a few words on building on top of to implement . Given the RCpc requirement, with the native , the only thing missing is the local ordering between acquire/release and ordinary memory operations. processor consistency release consistency processor consistency Like we said, usually the instruction set architecture will give you some control as to inserting barrier or fence instructions to enforce some kind of local ordering. has three of them, LFENCE, SFENCE and MFENCE. But only MFENCE is actually of any use to us. for example, has DMB and DSB instructions that function similarly. Now we're good to go! X86 ARM Even though there are a myriad of consistency models, is the weakest of them all that works. That's why you can ignore all other consistency models such as and so on. And even isn't all that interesting to understand either, aside from the fact that it's the consistency model of THE x86. release consistency causal, weak ordering, PowerPC x86 TSO Coda: Revisit our spinlock implementation Now that you have understood how works, you can probably see that our spinlock implementation at the beginning can be somehow improved in that the atomic accesses to the lock state don't have to be . release consistency sequential consistency There are other spinlock implementations from established orgs. The simplest is Facebook's . Our simplest example is just a tiny bit different from it, in that: folly Folly tries to avoid when possible. sequential consistency If a spinlock acquire operation fails, it executes the PAUSE x86 instruction to wait for a tiny bit. This tells the processor to kill all speculative executions to make space for other hyperthreads on the same core. We can definitely incorporate the memory order weakening part into our implementation easily: {
public: lock() { (;;) {
      bool expected_val = ; (busy.compare_exchange_strong(expected_val, , ::memory_order_acquire, ::memory_order_relaxed)) ;
    }
  } unlock() { busy.store( , ::memory_order_release); }

private:
  std::atomic<bool> busy = ;
}; class spinlock void for false if true std std return void false std false Now there's a funny thing. I won't paste it here, but if you watch the binaries from these two versions, you won't observe a tiny bit of difference. Why? ? At the very least would you think you should see some memory fence instructions removed in the new implementation The reason is the instruction itself brings an implicit memory barrier. So a call on x86 with weakened memory ordering isn't all that meaningful, because the architecture doesn't give the compiler an option. cmpxchg compare_exchange As to the release, remember only brings loads forward, bypassing stores to different locations? There's never a time it will reorder instructions backwards, so the "release" semantics is automatically guaranteed. x86 TSO Recapitulation and what's to come In this post we learned: Most of the time, shared variables are protected by locks. This has been the case since the uniprocessor days. takes advantage of this fact, and presents a much more feasible model for hardware, while maintaining the illusion of when variables are properly protected by locks. Release consistency sequential consistency Because lock acquisition can be retried, can work with weaker consistency models between synchronization ops. release consistency On x86, no memory fence is needed for locks, because the relevant instructions automatically bring order fences. This is quite a long post. And thank you for following this far. The fundamental architectural concepts are finally out of the way, in our next article, we'll switch gears and discuss some very practical topics. We'll first introduce some operating system concepts and spinlock's kin, mutex lock. We'll then look at how they perform in a very typical workload in real programming languages, pointing out potential directions for more advanced synchronization techniques.

Stories, News & Mentions about BOWSYCOM

Bowsycom’s Stories on HackerNoon