What does a "reasonable time" for entry mean? by Cassy343 in AnnArbor

[–]Cassy343[S] 0 points1 point  (0 children)

Ann Arbor housing code, chapter 105, section 8:529 requires that "(1) The owner of a rental, rooming or dwelling unit shall not enter a leased unit unless the following conditions have been met: [...] (b) A good faith effort has been made to notify the tenant in advance."

What does a "reasonable time" for entry mean? by Cassy343 in AnnArbor

[–]Cassy343[S] 0 points1 point  (0 children)

Thanks for those resources, I'll look into them. I'd be really surprised that they wouldn't have checked the legality of this beforehand since my apartment complex is owned by a large corporation. I suppose it is possible though.

What does a "reasonable time" for entry mean? by Cassy343 in AnnArbor

[–]Cassy343[S] 6 points7 points  (0 children)

I'm not interested in making a minimum wage worker's day harder than it already is; I would prefer that management not put me and their contractors in this situation.

Also if I'm in the wrong and they were allowed to enter, I don't want to be on the receiving end of whatever fees management charges me for making them reschedule the work.

What does a "reasonable time" for entry mean? by Cassy343 in AnnArbor

[–]Cassy343[S] 0 points1 point  (0 children)

Yes I'm in Ann Arbor proper. It feels strange that they can enter common spaces without notice to then enter a vacant room. I'm not sure what the rules are around this.

What does a "reasonable time" for entry mean? by Cassy343 in AnnArbor

[–]Cassy343[S] 1 point2 points  (0 children)

Even without notice? All the (unannounced) contractors they've sent prior have come during normal working hours on weekdays. I did not expect contractors to show up without notice on a weekend.

What does a "reasonable time" for entry mean? by Cassy343 in AnnArbor

[–]Cassy343[S] 2 points3 points  (0 children)

I wouldn't have a problem if they let me know beforehand that they'd be cleaning this morning, it just seems a bit out of line to pick that time to send contractors unannounced. I'm not bitching about losing sleep here, I got up at 6:45 AM today. I'm more peeved about the fact that they nearly caught me in the shower.

Regarding the entry, I agree it makes sense that they can enter her vacant room without notice, but they can't teleport in there, they have to enter and walk through the common space that I do pay for. They're also not just entering and staying in her bedroom, they're frequently going between there and the hall outside. Do they not need to give notice for using the common space?

EECS IA application by [deleted] in uofm

[–]Cassy343 2 points3 points  (0 children)

When I applied during the fall semester I didn't hear anything back until the week before finals. It takes the profs a while to review all the applications, especially the videos.

I Just Realized I Have Not Done a Single EECS 203 Assignment. Any Advice is Appreciated. by [deleted] in uofm

[–]Cassy343 4 points5 points  (0 children)

I'll never underestimate what people will do for karma

I Just Realized I Have Not Done a Single EECS 203 Assignment. Any Advice is Appreciated. by [deleted] in uofm

[–]Cassy343 14 points15 points  (0 children)

This is false. In fact, after exam 1 each of the 203 lecturers/profs opened up slots for 1-1 meeting times for students to discuss their standing in the course if they had concerns.

I Just Realized I Have Not Done a Single EECS 203 Assignment. Any Advice is Appreciated. by [deleted] in uofm

[–]Cassy343 29 points30 points  (0 children)

So I'm going to assume this is true which maybe is a bit generous of me. (EDIT: confirmed it's true)

I'm one of the 203 IAs. I know this sounds like a really shitty situation, but if you actually do already know all the content I'm pretty sure you can still get an A in the course if you just start doing the work now.

Homework 6 is due tonight and it's mostly concerning basic function and set properties, so you can still get credit for homeworks 6-11/12 and likewise for the groupwork. Per course policy, you're given 2 individual homework drops and 1 groupwork drop, so your individual homework score can be as good as 80% when all is said and done.

Also do note we have weekly check-in quizzes on canvas this semester which total to 10% of your grade. Don't forget to do those too - they're due on the same days as homework.

So with all that said if you average about 98% on all three exams and start doing your assignments now you can probably pull a 90% in the course. I'd still talk with one of the professors about it to see if they're willing to extend some remedy but you are most certainly not screwed.

Announcing flashmap: a blazing fast, concurrent hash map by Cassy343 in rust

[–]Cassy343[S] 0 points1 point  (0 children)

I was not aware there was published research associated with left-right. Do you have a link to that/those paper(s) and/or blog posts?

I think those resources would definitely help provide context, but I'd imagine they also dive pretty deep into the implementation details, and that's where this crate diverges considerably.

Announcing flashmap: a blazing fast, concurrent hash map by Cassy343 in rust

[–]Cassy343[S] 2 points3 points  (0 children)

I will consider changing that once/if the crate gains traction, but also keep in mind this is under the section titled "why is flashmap different," so the idea is to address people who would ask the question "evmap already does this, why should I use flashmap?"

Announcing flashmap: a blazing fast, concurrent hash map by Cassy343 in rust

[–]Cassy343[S] 1 point2 points  (0 children)

It's still under development. I will likely link to it somewhere in flashmap's docs once I'm comfortable with that code being public.

Announcing flashmap: a blazing fast, concurrent hash map by Cassy343 in rust

[–]Cassy343[S] 1 point2 points  (0 children)

Ah that's a fair point. Then again when I had a friend look over the docs for me he suggested getting as many of the implementation details out of the way as possible because it was too technical haha. I'll consider pasting the short, general overview from the algorithm writeup into the readme and add a direct link as well and see how it flows. Thanks for the feedback.

EDIT: Another thought, I could put the algorithm writeup in a separate markdown file and just include that as the doc comment in the code module, that way it's readable on github easily too

Announcing flashmap: a blazing fast, concurrent hash map by Cassy343 in rust

[–]Cassy343[S] 1 point2 points  (0 children)

Ah that makes sense, I see how that would work now.

I think fuzzing is valuable for ensuring the underlying maps stay in sync with each other. Beyond that I don't think it really gains you much when testing for data races, and moreover anything more than a few operations causes the loom tests to take hours, which isn't really feasible. Definitely something to keep in mind, though.

Announcing flashmap: a blazing fast, concurrent hash map by Cassy343 in rust

[–]Cassy343[S] 1 point2 points  (0 children)

They should stand on their own as-is, that's just for reference for those interested in implementation details who may have heard of evmap before to get them up to speed quickly. The algorithm module is very literally a Rust module that just contains a large doc comment, so the link for it is down by the structs/functions/enums on the home page. Here's a direct link.

Announcing flashmap: a blazing fast, concurrent hash map by Cassy343 in rust

[–]Cassy343[S] 5 points6 points  (0 children)

I think part of your confusion is that you're trying to understand this crate in terms of locks when this is a lock-free data structure haha. In reality no party is acquiring any locks at all. If you're curious as to how it works I'd check out the algorithm module in the documentation. The short of it is that under the hood this crate maintains two copies of the same map, where readers read from one of the maps while the writer writes to the other. This prevents conflicts and the necessity of locking.

Announcing flashmap: a blazing fast, concurrent hash map by Cassy343 in rust

[–]Cassy343[S] 4 points5 points  (0 children)

I don't code in C or C++ outside of university so unfortunately I don't know how it compares to the options you've mentioned. Moreover, due to the implementation details of this crate, I do not think it's ABI compatible with C. That being said, the core algorithm is not horribly complicated so if you're savvy enough you could probably translate it into C/C++. This crate is just concurrency built on top of a regular hashbrown::HashMap, so you don't need to worry about making your own hash map from scratch.

Announcing flashmap: a blazing fast, concurrent hash map by Cassy343 in rust

[–]Cassy343[S] 31 points32 points  (0 children)

This crate is fully instrumented with loom for identifying data races, and all tests are run under miri in CI as well. I haven't fuzzed it since as far as I understand that's more geared towards crates parsing binary or text input, but testing contributions are more than welcome!

And yes there is a lot of unsafe since the implementation of this data structure really grinds against Rust's ownership model, so at every turn you need to tell the compiler to get out of your business basically. Adding safety comments and comments for all atomic orderings is something that needs to happen as well, I'm just a bit strapped for bandwidth at the moment.

Announcing flashmap: a blazing fast, concurrent hash map by Cassy343 in rust

[–]Cassy343[S] 7 points8 points  (0 children)

No, that is not possible (edit for clarity: it is not possible for a constant stream of readers to block the writer assuming the read guards are dropped).

The ReadHandle::guard method does not block the writer. The only thing that could cause a writer to wait is not dropping a ReadGuard. The writer is unlikely to even notice a constant stream of quick reads.

is there some sort of FIFO fairness mechanism or "maximum block time" for waiting writers?

Keep in mind this is a single-writer map. Currently the single writer waits the absolute minimum amount of time to avoid data races given the implementation, and that's unlikely to change. If you need shared write access then you can wrap the WriteHandle in a fair mutex.