Upon our arrival at UChicago, Michelle (fellow DREU intern with Professor Lu) and I met with Professor Lu and her PhD students for lunch, then met with the tech staff and administrative staff in the CS department to get our CS accounts and UChicago IDs set up. Our first meeting in which we talked about our project was Wednesday, June 17th.
In the meeting, Professor Lu spoke to us about the overall goals of the project (which we were already pretty familiar with due to having spoken to her before arriving), and we got into some detail about multi-threaded software. More about the project goals below! As neither Michelle nor I have ever written concurrent software before, Professor Lu explained the basics to us and assigned us a series of readings in an online textbook (along with practice code to implement) so that we could further familiarize ourselves with writing concurrent programs. We spent the rest of the week (through Sunday) working on the textbook examples and exercises so that when parsing and analyzing the source code revisions for our subject applications, we will be able to determine the effects of different critical section changes. It was helpful that Professor Lu assigned us text with lots of code we could implement because writing my own code and moving around the lock/unlock/signal/wait commands to see the effects of different practices allowed me to get a really good understanding of the types of changes we'll be seeing in our case study on Apache and Mozilla (as described below).
Project Goals: Michelle and I will each take a subject multi-threaded software project (Michelle will take Mozilla and I will take the Apache HTTP Server Project) and create scripts as well as perform manual analysis to determine what types of changes pertaining particularly to signaling/waiting on condition variables are most prevalent and cause developers the most trouble in creating multi-threaded software. Obviously both these software projects are highly multi-threaded so they lend themselves well to such a study. They are also open-source so we can access all changes in the projects' version control repositories (SVN in my case). Ultimately we hope to gain some insight about what challenges developers face when writing multi-threaded software so that future researchers might be able to develop automatic algorithms and tools to assist with adding synchronization to software.
I completed my background research on concurrent programming and concurrency bugs on Sunday, June 21st and that night I began reviewing the APIs of some of Apache's concurrency-related modules. My goal here was to familiarize myself with the wrapper functions Apache developers would use to implement locking, signaling, and waiting procedures whenever they don't directly use the POSIX library for this. This proved to be a good idea, because in our next meeting with Professor Lu (the following day), when I told her about my findings, she confirmed that another undergraduate student had written a similar script to analyze MySQL but had not considered the possibility of wrapper functions for synchronization procedures, which set that student back a bit in her progress.
In the meeting, Professor Lu spoke to us about the overall goals of the project (which we were already pretty familiar with due to having spoken to her before arriving), and we got into some detail about multi-threaded software. More about the project goals below! As neither Michelle nor I have ever written concurrent software before, Professor Lu explained the basics to us and assigned us a series of readings in an online textbook (along with practice code to implement) so that we could further familiarize ourselves with writing concurrent programs. We spent the rest of the week (through Sunday) working on the textbook examples and exercises so that when parsing and analyzing the source code revisions for our subject applications, we will be able to determine the effects of different critical section changes. It was helpful that Professor Lu assigned us text with lots of code we could implement because writing my own code and moving around the lock/unlock/signal/wait commands to see the effects of different practices allowed me to get a really good understanding of the types of changes we'll be seeing in our case study on Apache and Mozilla (as described below).
Project Goals: Michelle and I will each take a subject multi-threaded software project (Michelle will take Mozilla and I will take the Apache HTTP Server Project) and create scripts as well as perform manual analysis to determine what types of changes pertaining particularly to signaling/waiting on condition variables are most prevalent and cause developers the most trouble in creating multi-threaded software. Obviously both these software projects are highly multi-threaded so they lend themselves well to such a study. They are also open-source so we can access all changes in the projects' version control repositories (SVN in my case). Ultimately we hope to gain some insight about what challenges developers face when writing multi-threaded software so that future researchers might be able to develop automatic algorithms and tools to assist with adding synchronization to software.
I completed my background research on concurrent programming and concurrency bugs on Sunday, June 21st and that night I began reviewing the APIs of some of Apache's concurrency-related modules. My goal here was to familiarize myself with the wrapper functions Apache developers would use to implement locking, signaling, and waiting procedures whenever they don't directly use the POSIX library for this. This proved to be a good idea, because in our next meeting with Professor Lu (the following day), when I told her about my findings, she confirmed that another undergraduate student had written a similar script to analyze MySQL but had not considered the possibility of wrapper functions for synchronization procedures, which set that student back a bit in her progress.