Tag Info

Hot answers tagged

20

This is an oddly phrased question that is really, really broad if answered fully. I'm going to focus on clearing up some of the specifics that you're asking about. Immutability is a design trade off. It makes some operations harder (modifying state in large objects quickly, building objects piecemeal, keeping a running state, etc.) in favor of others ...


17

It sounds to me like they are leading you toward a semaphore solution. Semaphores are used to signal another thread that it's their turn. They are used much less frequently than mutexes, which I guess is why they think it's a good interview question. It's also why the example seems contrived. Basically, you would create m semaphores. Each thread x waits ...


14

The only difference between the two is the synchronization used in StringBuffer. The overhead of synchronization is not huge in the grand scheme of things, but it is significant relative to the StringBuilder methods that don't have them. The JVM is doing work that it wouldn't otherwise have to do--especially with only one thread, etc. If your code works ...


13

Interview questions are sometimes actually trick questions, intended to make you think about the problem that you're trying to solve. Asking questions about a question are an integral part of approaching any problem, whether it's in the real world or in an interview. There are a number of videos circulating the internet on how to approach questions in ...


11

We use both Redis and Zookeeper at work so this is from first hand experience Redis is fast; really, really fast. It is also immediately consistent, so it's good for fast moving data sets. The downside is that, running on one server, if it fails then you lose write access until another server takes it's place. Replacing the server is a manual operation ...


11

In my opinion, this is a fabulous interview question -- at least assuming (1) the candidate is expected to have deep knowledge of threading, and (2) the interviewer also has deep knowledge and is using the question to probe the candidate. It's always possible that the interviewer was looking for a specific, narrow answer, but a competent interviewer should ...


8

The usual solution for knowing "which change is correct" is a vector clock. You essentially keep track of counters for each repository that holds the data, and reject changes if a particular client's view of everyone else's state differs from that of the peer it is connecting to. The big question that you have to answer is how you'll resolve rejected saves. ...


8

A function that accepts some value and returns some other value, and doesn't disturb anything outside of the function, has no side effects, and is therefore thread-safe. If you want to consider things like how the way the function executes affects power consumption, that's a different problem. I am assuming that you're referring to a Turing-complete ...


7

This is the Byzantine Generals problem, which is unsolvable. You can never guaranteed synchronize the two servers if you cannot guarantee that at some time in the future, you will have sufficient reliable bandwidth to perform the synchronization all in one go.


7

On Windows there's a mechanism to have the OS alert you when there's a change to a 'watched' directory structure - FindFirstChangeNotification(). When that indicates a file has changed, an application can then go about comparing files in the changed directory to find the actual files that have changed by looking at size, modified date, hash, etc. This (as ...


7

You can abstract the transaction as an object in itself, which then provides a single interface to manage the transaction and its participants. First property of transactions, Atomicity satisfies your requirement of atomicity/single point. I.e. something like this: public class Transaction { ... private Account _source; private Account ...


6

Where and what are the resources? REST is all about addressing resources in a stateless, discoverable manner. It does not have to implemented over HTTP, nor does it have to rely on JSON or XML although it is strongly recommended that a hypermedia data format is used (see the HATEOAS principle) since links and ids are desirable. So the question becomes how ...


6

Is there any algorithm that must use one of them in its implementation? Almost certainly not. (Indeed, from the theoretical perspective, you should be able to simulate wait / notify using other java.util.concurrent.. classes. And synchronized could be replaced with explicit Lock operations ... though you would need to be careful to unlock in finally ...


5

Client 1 connects, checks for an active lock on key 1, finds none, and gets the data You should not test for lock then create it, but rather attempt to create it with Memcache::add, which will either create lock or fail. It does so atomically, so you'll no longer have TOCTTOU race condition. $mc= new Memcache; $mc->connect('localhost', 11211); ...


5

The reason is nothing to do with race conditions, or the method returning a value that you can't rely on: If the current thread holds the lock before the test, it is guaranteed to hold it after the test. If the current thread doesn't hold the lock before the test, it won't hold it after the test. This situation will only change if the thread executes a ...


5

No, Dropbox and any decent synchronization tool relies on file system events. All operating systems offer such events and programs like Dropbox are just simply listening for changes on files they are watching. When a change happens, or file is added / deleted, Dropbox decides what it has to do. If several events happen while others are in progress, they a ...


5

Since what you are really talking about here is a stylistic/readability issue (at least, that's the way I read it), you might be a little out of luck, because all the all alteratives I can think of aren't great. Really you have two options, write multiple distinct functions like you have done above, or use closures to bring it all "inline" (as it were), ...


5

Promises were made to solve problems like this; they work really well in functional languages (I've personally used them extensively in Javascript, where curiously jQuery actually has the worst implementation of them - see this comparison). The weird thing about using promises is accepting that things are easier when you make everything use them. I will ...


4

That's probably because the best way to tell if you hold a mutex is that there's a lock a few lines up. If your mutexes are being held longer than that, your software needs some rearchitecting.


4

I'm inclined to agree with you for the reasons you state. Also, if you use the same database, you also get a very practical business benefit - you can easily 'upgrade' a customer to the full version without a complicated data export/import. One thing you might recommend is trying it first with the one database approach. If that becomes a problem, its far ...


4

This is a hard problem. I do not believe REST is an appropriate level to implement sync. A robust sync would essentially need to be a distributed transaction. REST is not the tool for that job. (Assumption: by "sync" you are implying that either resource can change independently of the other at any time, and you want the ability to realign them without ...


4

For each event, besides its "event time" you also need to keep track of one more time attribute, the time of last modification. This takes care of the simple and, ehm, lets say, uneventful sync scenario: events that have been modified since the last sync time get copied over. The problems start if there is a possibility that two events may have both been ...


4

I can't guarantee that this would solve the issues you're running into, but Queuing is often used to chain a series of asynchronous calls so that they happen one after another. I wrote a Queue script a while ago which I will be using as an example: (function () { var q = new Queue(); q.queue(function (next) { //this gets run first ...


4

You should look into Deferreds. You can implement your functions and execute them sequentially, regardless of the fact the the code inside the function is async. Once the first finishes the second will be triggered and so on.


4

You should look at how distributed change management works. Look at SVN, CVS and other repositories that manage deltas work. You have several use cases. Synchronize changes. Clients send their deltas to the server; server consolidates and distributes the deltas to the clients. This is the typical case. Databases call this "transaction replication". Client ...


4

You are confused. Synchronizing two different instances of similar data requires knowing which version is correct if there is a discrepancy. If an email message is on one side and not on the other, how do you know whether you should replay a "delete" on the one side, or an "add" on the one side? If email messages with the same ID differ in their content, ...


3

The actual logistics of this aren't too tricky (last-modified date on each record, and a "disconnected-since" or "last-synced" timestamp stored somewhere), the real issue is probably going to be your conflict resolution technique. What should the system do when two people modify the same field in the same record? I'd suggest logging all offline changes ...


3

My approach is to develop a web service that has all of the business rules and data rules encoded in it and exposes objects that can be used by both a web based app and a desktop app.


3

For hotels there is a third requirement you're not thinking of - exposing yourself to aggregation sites (think Expedia) for bookings. If this is a requirement (and it probably is when they ask "so how do we sell through Expedia") then synchronisation sort of goes out of the window (there are ways around it but really you all want to look at the same data ...



Only top voted, non community-wiki answers of a minimum length are eligible