
M. A. Deppert, K. Jansen, M. Maack, S. Pukrop, and M. Rau 3
the conflict graph. There are many positive and negative results for different versions of this
problem (see, e.g., [
1
,
14
] and the references therein). For instance, the problem is NP-hard
on cographs with unit-size jobs but polynomial time solvable if the number of machines is
constant [6]. Note that in the case of MSRS, we have a particularly simple cograph, i.e., a
collection of disjoint cliques.
Results.
We present a 5
/
3-approximation in Section 2, a 3
/
2-approximation in Section 3,
approximation schemes in Section 4, and inapproximability results in Section 5. Note that
the 5
/
3- and 3
/
2-approximation have better approximation ratios than the previously known
(2m/(m+ 1))-approximation already for 6 and 4 machines, respectively.
The 5
/
3-approximation is a simple and fast algorithm that is based on placing full classes
of jobs taking special care of classes containing jobs with particularly big sizes and of classes
with large processing time overall. While the 3
/
2-approximation reuses some of the ideas
and observations of the first result, it is much more involved. To achieve the second result,
we first design a 3
/
2-approximation for the instances in which jobs cannot be too large
relative to the optimal makespan and then design an algorithm that carefully places classes
containing such large jobs and uses the first algorithm as a subroutine for the placement of
the remaining classes. Note that our approaches are very different to the one in [
17
], which
successively chooses jobs based on their size and the size of the remaining jobs in their class
and then inserts them with some procedure designed to avoid resource conflicts, and the one
in [29], which merges the classes into single jobs to avoid resource conflicts.
We provide an EPTAS for the variant of MSRS where the number of machines is
constant and an EPTAS with resource augmentation for the general case. In particular, we
need
b
(1 +
ε
)
mc
many machines in the latter result. Both results make use of the basic
framework introduced in [
19
] which in turn utilizes relatively recent algorithmic results
for integer programs (IPs) of a particular form – so-called N-fold IPs. Compared to the
mentioned work by Dósa et al. [
11
] – which provides an EPTAS for the case with a constant
number of machines as well – our result is arguably simpler and faster (going from at least
triply exponential in
m/ε
to doubly exponential). We also provide the result with resource
augmentation for the general case, which may be refined in the future to work without
resource augmentation as well. Moreover, it seems plausible that the use of N-fold IPs in
the context of scheduling with additional resources may lead to further results in the future,
which do not have to be limited to approximation schemes.
Finally, we provide inapproximability results for variants of MSRS where each job may
need more than one resource. In particular, we show that there is no better than 5
/
4-
approximation for the variant of MSRS with multiple resources per job, unless
P
=
NP
,
even if no job needs more than three resources and all jobs have processing time 1, 2 or 3.
Previously, the APX-hardness result due to Even et al. [
14
] for scheduling with conflicts was
known, which did focus on a different context and in particular does not provide bounds
regarding the number of resources a job may require.
Further Related Work.
As mentioned above, there exists extensive research regarding
scheduling with additional resources and we refer to the surveys [
2
–
4
,
12
] for an overview.
For instance, the variant with only one additional shared renewable resource where each job
needs some fraction of the resource capacity has received a lot of attention (see [
21
,
22
,
26
,
27
]
for some relatively recent examples). Interestingly, Hebrard [
17
] pointed out that this basic
setting is more closely related MSRS than it first appears: Consider the case that we have
dedicated machines, i.e., each job is already assigned to a machine and we only have to